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This  technical  report  summarizes  the  research 
activities  performed  hy  the  Information  Sciences 
Institute  of  the  University  of  Southern  California 
during  the  period  17  May  1972  to  16  May  1973 
under  Contract  No.  DAHC15  72  C  0308,  ARPA 
Order  No.  2223/1,  Program  Code  No.  3D30  and 
3P10  with  the  Advanced  Research  Projects 
Agency,  Information  Processing  Techniques  Office. 
The  research  is  oriented  toward  the  application  of 
computer  science  and  technology  to  problem  areas 
of  high  impact. 

The  research  program  is  composed  of  five  (de¬ 
ments:  1)  Programming  Research  Instrument  -  the 
development  and  exploration  of  a  major  time- 
shared  microprogramming  facility;  2)  Automatic 
Programming  -  the  study  of  acquisition  and  utili¬ 
zation  of  problem  knowledge  for  program  genera¬ 
tion;  3)  Computer  Software  Assurance  -  methods 
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to  assess  the  viability  of  the  security  and  protec¬ 
tion  mechanisms  of  operating  system  software;  4) 
Network -,S'up/>orting  Research  -  packet -switched 
network  communications  technology  development, 
including  voice,  data,  and  image  use  in  remote 
conferencing  applications;  and  5)  Programmed  Au¬ 
tomation  -  the  application  of  computer  science 
technology  to  automation  of  DOD  high  procure¬ 
ment  areas,  including  impact  studies  anil  defini¬ 
tion  of  development  requirements. 

Also  reported  is  the  development  and  operation  of 
TENEX  computer  facilities  supporting  ARPA- 
sponsored  Institute  projects  and  some  400  external 
users  via  the  ARPANET. 
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OVERVIEW 


The  Information  Sciences  Institute  (ISI),  a 
research  unit  of  the  University  of  Southern 
California’s  School  of  Engineering,  was 
formed  in  May  1972  to  do  research  in  the 
fields  of  computer  and  communications  sci¬ 
ences  with  an  emphasis  on  systems  and  ap¬ 
plications.  The  Institute,  located  off-campus, 
has  sufficient  autonomy  within  the  University 
structure  to  assure  it  the  freedom  required  to 
identify  and  engage  in  significant  research 
programs. 

At  the  end  of  the  first  year  of  operation. 
ISl’s  full-time  professional  research  staff 
numbers  25.  Total  project  support  at  ISI,  in¬ 
cluding  full-time  staff,  participating  faculty 
and  graduate  students,  and  support  personnel, 
is  currently  at  60  people. 

A  close  relationship  is  maintained  with 
USC  academic  programs  through  active  coop¬ 
eration  between  ISI,  the  School  of  Engineering, 
the  Department  of  Electrical  Engineering,  and 
the  Computer  Science  Program.  Ph.D.  thesis 
supervision  is  an  integral  part  of  1S1  pro¬ 
grams.  Also,  participating  faculty  and  gradu¬ 
ate  students  from  other  departments  provide 
the  interdisciplinary  capabilities  for  Institute 
projects. 

ISI  has  five  major  projects  supporting 
ARPA/IPT  research  areas.  These  projects  in¬ 
clude  the  following  elements: 

PROGRAMMING  RESEARCH  INSTRU¬ 
MENT:  Development  and  exploration  of 
time-shared  microprogramming  facilities  to 
service,  via  the  ARPANET,  language 
processing,  emulation,  and  special  func¬ 
tional  n  leds. 


AUTOMATIC  PROGRAMMING:  Definition 
and  contributing  research  in  automatic  pro¬ 
gramming,  including  problem  acquisition, 
modeling,  and  code  production. 

COMPUTER  SOFTWARE  ASSURANCE: 
Studies  and  development  of  methodologies 
for  system  software  security  and  protection, 
including  software  design  concepts,  formal 
program  verification,  and  empirical  mea¬ 
surement  efforts. 

NETWORK  -SUPPORTING  RESEARCH: 
Research  and  development  of  packet - 
switched  network  use  in  secure  natural 
communications,  including  voice,  image, 
and  iextual  data;  remote  subroutine  use, 
and  special  studies  in  network  applications 
for  DOD  environments. 

PROGRAMMED  AUTOMATION:  Defini¬ 
tional  studies  leading  to  programmable  au¬ 
tomation  of  job  shop  environments,  includ¬ 
ing  impact  studies  on  DOD’s  procurements 
and  recommendations  for  development  pro¬ 
grams  required  to  realize  such  automated 
systems. 

ISI  has  conducted  several  smaller  projects 
related  to  more  immediate  DOD  needs.  These 
have  included  a  study  and  comprehensive 
report  proposing  a  means  for  total  automation 
of  military  message  services  on  the  island  of 
Oahu,  Hawaii;  work  in  the  definition  and 
implementation  of  ARPANET  accounting 
practices;  and  definition  and  development  of  a 
general-purpose,  high  quality  terminal  dis¬ 
play  and  hard  copy  Facility. 

ISI  has  implemented  and  maintained  a  ma¬ 
jor  TENEX  computing  facility  in  support  of 
Institute  projects  and  other  ARPA  programs 
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OVERVIEW 

via  the  ARPANET.  This  system  is  now  the 
busiest  node  on  the  ARPA  Network;  operating 
at  full  capacity  it  has  attracted  some  400 
users  in  its  first  8  months  of  service. 

The  blend  of  talents,  along  with  a  full-time 
commitment  to  research  by  the  staff,  has  re¬ 
sulted  in  the  creation  of  a  new  institute  well 


suited  to  contemporary  research  needs  and 
required  accomplishments. 

The  following  is  a  report  on  research  pro¬ 
jects  initiated  in  the  first  year  of  operation  of 
1S1. 
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2  PROGRAMMING  RESEARCH  INSTRUMENT 


INTRODUCTION 

The  Programming  Research  Instrument 
(PRIM)  project  is  creating  a  fully  protected 
experimental  computing  environment  with 
continuous  multi-user  access.  The  I/O  and 
user  interaction  facilities  will  be  provided  by 
Bolt  Beranek  and  Newman's  Inc.  (BBN) 
TENEX  time  sharing  system.  The  computa¬ 
tional  facilities  will  be  provided  by  the  MLP- 
900,  a  flexible  and  powerful  microprogram¬ 
med  processor  developed  by  the  STANDARD 
Computer  Corporation.  PRIM  will  provide  a 
multi -access  system  in  which  each  researcher 
can  create  his  own  specialized  computing  en¬ 
gine  capable  of  being  changed  and  adapted  to 
his  specific  needs.  This  facility  will  be  availa¬ 
ble  to  users  through  the  1SI  TENEX  host  con¬ 
figuration  on  the  ARPANET. 

The  PRIM  project  will  create  an  AR- 
PANET-based  sharable  design  environment, 
which  will  be  used  as  a  means  of  exploring 
computer  architecture,  language  development, 
and  special  purpose  processor  design.  These 
factors  are  all  of  particular  relevance  to  1X)D 
selection  and  use  of  computer  equipment. 


Project  Leader:  Thomas  O.  Ellis 

Research  Staff:  Stuart  (’.  Feigin 

l^/uih  Gallenson 
Robert  E.  Hoffman 
Raymond  L.  Mason 
John  T.  Melvin 
Donald  R.  Oestreicher 

Research  Support  Staff:  R.  Jat-que  Bruninga 

George  W.  Dietrich 
Oralio  E.  Garza 
Mary  J.  Jaskula 
Lloyd  G.  Jensen 

Research  Assistants:  John  M.  Malcolm 

Martin  I).  Yonke 


As  with  the  first  generation  CPUs  10  years 
ago,  most  microprocessors  now  operate  in  a 
single-user  environment.  Thev  have  only 
minimal  operating  systems  and  are  dedicated 
to  a  single  application.  This  type  of  configu¬ 
ration  makes  the  general  availability  of  a 
microprogrammed  resource  both  difficult  and 
expensive. 

The  reasons  for  this  situation  are  familiar 
from  10  years  ago.  First,  most  microprocessors 
have  not  been  structured  to  allow  for  time 
sharing  at  the  microprogramming  level.  Most 
are  devoid  of  the  proper  protection  and  inter¬ 
rupt  facilities  to  support  this  kind  of  operat¬ 
ing  system.  Second,  control  memory  is  too 
expensive  and,  as  a  result,  too  small  for  users 
to  be  willing  to  give  up  any  significant 
amount  of  core  space  to  a  time  sharing  sys¬ 
tem.  Finally,  the  unfamiliar  architecture  of 
microprocessors  is  difficult  to  program  and 
high-level  language  tools  are  rarely  available. 

These  problems  have  been  occupying  the 
PRIM  project  for  the  past  year.  Solutions  are 
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PROGRAMMING  RESEARCH  INSTRUMENT 

now  a»  hand,  and  a  time-shared  mieroproces- 
sor  should  be  available  to  ARPANET  usert 
sometime  in  the  late  summer  of  1973. 

PRIM  Hardware  Resources 

This  system  is  based  on  two  processors:  the 
Digital  Equipment  Corporation  (DEC)  PDP-10. 
and  the  STANDARD  Computer  Corporation 
MLP-900  prototype  processor.  (Six;  Figure  2.1.) 

rhP-io. 

The  PDP-10  has  a  BBN  paging  box  and 
runs  the  BBN  TENEX  time  sharing  system. 
The  processor  has  256K  words  of  36  bit  mem  - 
ory,  and  is  connected  to  the  ARPANET.  In 
order  to  simplify,  and  thus  minimize,  the  mi¬ 
croprogram  supervisor  (rnicrovisor)  in  the  mi¬ 
croprocessor,  all  I/O  ,vill  he  done  hy  TENEX. 
This  includes  files,  terminal  and  network 
handling,  swapping,  and  all  other  accesses  to 
peripheral  devices. 


F inure  2.  1  Basic  FFW  confiauration. 
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The  MLP-900  |l-.‘l]  is  a  vertical  word  mi¬ 
croprocessor  which  runs  synchronously  with 
a  5MHz.  clock.  It  is  characterized  by  two 
parallel  computing  engines:  the  Operating 
Engine  (OE)  and  the  (Control  Engine  (CE).  The 
OE  performs  arithmetic  operations  and  the 
CE  control  operations.  The  OE  contains  32  36- 
hil  general-purpose  registers  for  operands, 
and  32  36- hit  mask  registers  to  specify  oper¬ 
and  fields.  The  CE  contains  256  state  flip/ 
flops.  The  CE  also  contains  a  16  word  hard¬ 
ware  subroutine  return  stack  and  16  8-bit 
pointer  registers.  The  writable  control  mem¬ 
ory  contains  4K  words.  There  is  a  IK  36-bit 
high  speed  auxiliary  memory  associated  with 
the  OE. 

The  OE  and  CE  will  execute  in  parallel  if, 
and  only  if.  a  CE  instruction  follows  an  OE 
instruction  in  control  memory.  Programmer 
consideration  of  this  feature  usually  is  not 
required.  However,  f  a  program  is  executed 
entirely  as  nE-CF,  instruction  pairs,  the  ef¬ 
fective  machine  speed  is  doubled. 

The  speed  and  power  of  the  MLP-900  may 
he  conveniently  characterized  by  its  ability  to 
emulate  better  known  machines.  Emulation  of 
the  IBM  360  machine  language  instructions 
would  result  in  an  estimated  execution  rate 
between  0.5  and  1.0  that  of  an  IBM  360/65.  A 
PDP-10  can  he  emulated  at  a  rate  almost 
double  a  KA10  CPU.  However,  in  two  high- 
level  languages  investigated,  an  estimated  or¬ 
der -of -magnitude  increase  in  execution  rate 
of  source  statements  can  he  attained  by  im 
plementing  those  languages  directly  rather 
than  emulating  an  intermediate  target  ma¬ 
chine. 


The  MLP-900  is  particularly  well  suited  for 
investigating  direct  language  emulation.  It  has 
the  flexibility  of  a  large  {4,096  word  x  36  bit) 
writable  control  memory.  The  basic  architec¬ 
ture  of  the  MLP-900  permits  convenient  ex  - 
pansion  through  the  use  of  special  purpose 
hardware  language  boards.  These  allow  easy 
expansion  and  increased  speed  for  specialized 
language  processing  tasks. 

The  environment  around  the  MLP-900  fur¬ 
ther  promotes  easy  experimentation  and  user 
access.  The  TENEX  host  system  will  not  only 
provide  complete  I/O  handling  for  the  MLP- 
900,  but  also  a  developed,  and  in  many  cases 
familiar,  environment  for  users.  Together 
these  two  advanced  systems  should  provide  a 
most  powerful  and  useful  tool. 

Hard trare  Effort 

The  hardware  group  has  made  modifica¬ 
tions  to  the  MLP-900  in  two  areas.  First,  the 
MLP-900  was  interfaced  to  the  PDP-10.  The 
resulting  modifications  included  memory  and 
I/O  buss  interfaces,  A  paging  box  was  also 
necessary  to  maintain  compatibility  with  the 
BBN  TENEX.  Second,  the  proper  protection 
features  were  added  to  support  a  microvisor 
end  preemptive  user  scheduling.  These  modi¬ 
fications  included  a  privileged  microvisor 
mode  and  processor  state  protections. 

Software  Effort 

The  software  group  has  worked  on  support 
software  and  microvisor  design.  Included  in 
the  support  effort  was  the  creation  of  a  high- 
level  General  Purpose  Microprogramming 
Language  (GPM)  for  programming  the  MLP- 
900.  In  addition,  the  STANDARD  Computer 
Corporation  MLP-900  diagnostics  have  been 
translated  into  GPM.  All  new  diagnostics  and 
software  will  be  done  in  GPM. 
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Mirror  isor  .Stair. 

’^he  introduction  of  a  microvisor  state  has 
been  of  major  importance  to  the  PRIM  project 
and,  significantly,  has  affected  other  research 
projects  in  both  the  private  and  public  sectors. 
Prior  to  this  project,  little  had  been  done  tow¬ 
ards  making  the  multiiude  of  mic'oprocessors 
potentially  sharable  resources.  This  initial  ex¬ 
periment  goes  a  long  way  toward  making  the 
microprocessor  widely  and  inexpensively 
available. 

Relerance  and  Impact 

When  the  PRIM  facility  is  complete,  it  will 
be  possible  to  quickly  and  easily  simulate 
new  hardware  architectures  and  designs  in 
microprogrammed  software.  That  is,  software 
can  be  created  for  hardware  not  yet  available, 
and  hardware  designs  may  be  extensively 
used  and  changed  before  the  cost  of  even  a 
breadboard  prototype  is  expended.  This 
should  both  cut  lead  lime  and  improve  deci¬ 
sions  connected  with  the  special  purpose 
hardwa<e  procurement  cycle. 

The  unique  PRIM  facility  will  be  a  proto¬ 
type  for  the  future.  As  microprogrammed 
computers  become  more  readily  available, 
PRIM  systems  will  become  more  important  as 
a  way  to  make  the  use  of  large  microproces¬ 
sor  systems  cost  effective.  The  PRIM -devel¬ 
oped  techniques  will  Ik;  as  important  as  the 
time  sharing  techniques  developed  10  years 
ago. 

HARDWARE 

The  hardware  effort  has  been  conducted  in 
three  broad  areas: 

1)  reconfiguring  the  mainframe  for  neces¬ 
sary  expansion,  improved  reliability,  and 

better  cooling; 
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2)  interfacing  the  MLP-900  to  the  PDP-10 
(including  I/O  and  memory  buss  interfaces, 
and  a  paging  facility); 

3)  creating  a  microvisor  state  within  the 
MLP-900  with  facilities  for  protection  of 
the  privileged  resources  and  appropriate 
communication  to  change  state. 

The  hardware  design  effort  has  linen  com¬ 
pleted  and  is  in  the  final  stages  of  implemen¬ 
tation.  Modification  to  the  mainframe  is  cur¬ 
rently  finishing  and  testing  of  the  modified 
processor  will  start  immediately.  The  ex¬ 
tended  software  diagnostics  will  assist  in  this 
effort  and  insure  the  integrity  of  the  proces¬ 
sor.  The  final  test  phase  will  he  the  integra¬ 
tion  of  the  MLP-900  with  TENEX  iri  a  dual 
processor  configuration. 

Mainframe  Reconfiguration 

The  first  hardware  implementation  task 
completed  was  the  reconfiguration  of  the 
mainframe  of  the  MLP-900  and  the  replace¬ 
ment  of  unreliable  subsystems,  The  orienta¬ 
tion  of  the  original  mainframe  (see  Figure  2.2) 
was  deficient  in  cooling  capabilities  and  did 
not  have  the  expansion  area  necessary  to 
house  needed  additional  functions.  The  frame 
was  rotated  90  degrees  (see  Figure  2,3)  and 
extended  to  provide  the  additional  hack  panel 
space  required.  The  new  configuration  also 
rotated  the;  logic  boards  from  the  horizontal  to 
the  vertical  plane  and  facilitated  an  improved 
cooling  system. 

Two  subsystems  that  proved  unreliable 
were  the  power  suppliers  and  the  control 
memory.  The  original  control  memory  was 
fabricated  with  ECL  memory  chips  (SC7301) 
produced  especially  for  the  STANDARD 
Computer  Corporation.  These  memory  chips 
consumed  too  much  power  and  the  fabricated 


Figure  2. 2  Original  MLP-900 
main f vane  configuration. 


Figure  2.3  Reconfigured  MLP-900 
mainframe. 


printed  circuit  memory  hoards  proved  to  he  ol 
unreliable  construction.  This  subassembly 
was  replaced  by  an  off-the-shelf  memory 
system  from  Cogar  Corporation  which  re¬ 
duces  power  consumption  at  the  expense  of 
speed.  The  Cogar  memory,  which  uses  bipolar 
technology,  has  an  access  lime  of  (>(!ns  as 
compared  with  the  4()ns  specified  for  the 
STANDARD  memory. 
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The  decision  to  replace  the  control  memory 
rather  than  repair  the  original  one  was  based 
primarily  on  the  guaranteed  improved  reli¬ 
ability.  Other  important  considerations  were: 
larger  memory  in  a  smaller  area  (the  new 
memory  is  4,096  words  of  40  bits,  compared  to 
the  original  memory  of  512  words  of  32  bits); 
minimized  heat  dissipation  problems;  and  off- 
the-shelf  components  for  future  expansion 
and/or  replacement  spares. 

(n  addition  to  refurbishing  the  cooling  sys¬ 
tem,  the  design  also  included  a  new  power 
buss  distribution,  a  power  control  panel,  a 
facility  for  simple  interface  cabling,  and  a 
confguration  which  could  lie  extended  with¬ 
out  revamping  the  existing  mainframe.  All 
these  changes  were  implemented  while  keep¬ 
ing  the  original  hack  panel  wiring  and  opera¬ 
tor’s  panel  intact. 

Interface  to  PDP-10 

The  interface  of  the  MLP-900  to  the  PDP- 
10  was  accomplished  by  implementing  a 
KA10  (CPU  of  the  PDP-10)  I/O  buss  connec¬ 
tion  to  a  register  connected  to  the.  Exchange 
Buss  of  the  MLP-900,  and  a  memory  buss 
from  the  MElOs  (main  memory  of  the  PDP- 
10)  to  the  Exchange  Buss  of  the  MLP-900  (see 
Figure  2.1).  The  Exchange  Buss  is  the  MLP- 
900  internal  register  buss  that  provides  data 
paths  for  all  registers  and  memories  of  the 
MLP-900. 


I/O  /fiis.i  Interface. 

The  I/O  interface  between  the  PDP-10  and 
the  MLP-900  (see  Figure  2.4)  is  designed  and 
constructed  to  physically  fit  into  the  MLP- 
900  to  achieve  the  following  goals: 


1)  It  is  logically,  electronically,  and  physi¬ 
cally  compatible  with  the  PDP-10  I/O  buss 
structure. 

2)  It  is  similarly  compatible  with  a  data 
line  scanner  via  simulator  to  communicate 
the  PDP-10  I/O  buss  information  over  a 
longer  distance  during  initial  checkout.  An 
I/O  buss  simulator  has  been  designed  and 
implemented  to  allow  a  normal  two  wire 
(TTY)  interface  to  the  KA10.  This  allows 
complete  checkout  of  the  buss  interface 
within  the  MLP-900  prior  to  connecting  to 
the  KA10  I/O  buss  directly. 

3)  It  provides  normal  mutual  communica¬ 
tion  for  service  requests  and  support  func¬ 
tions  between  the  PDP-10  and  the  MLP- 
900. 

4)  It  provides  positive  preemptive  control 
over  the  MLP-900  by  the  PDP-10  for  emer¬ 
gency  conditions. 

5)  It  provides  an  Initial  Program  Loading 
(1PL)  path  for  bootstrapping  and  emergency 
control  over  the  control  memory  contents. 

6)  It  provides  the  means  for  the  PDP-10  to 
freeze,  save,  and  restore  the  context  of  the 
I/O  interface. 

7)  It  provides  a  few  direct  indications  of  the 
MLP-900  status. 

8)  It  provides  adequate  access  paths  to  the 
registers  for  the  MLP-900  to  diagnose  the 
I/O  interface  for  error  conditions. 

9)  It  is  designed  for  minimum  interaction 
and  interference  between  the  MLP-900  and 
the  PDP-10  in  normal  operations. 

The  I/O  buss  interface  contains  four  regis¬ 
ters.  They  are: 
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1)  a  data  buffer,  called  DATAO/RECEIVE, 
to  receive  from  the  PDP-10  and  send  to  the 
MLP-900; 

2)  a  data  buffer,  called  DATAI/SEND.  to 
receive  from  the  MLP-900  and  send  to  the 
PDP-10; 

3)  a  command  and  status  register  to  accept 
commands  from  both,  and  to  send  out 
status  and  command  information  to  both; 

4)  a  counting  register  set  by  the  PDP-10 
and  used  to  address  control  memory  during 
Initial  Program  Loading. 

Main  Memory  Buss  interface. 

The  system  architecture  of  the  MLP-900 
integration  into  TENEX  requires  the  sharing 
of  a  common  main  memory  which  results  in  a 
dual  processor  configuration.  The  functional 
requirements  of  the  interface  are: 

1)  to  provide  Icgic  level  compatibility  be¬ 
tween  the  MLP-900  and  the  MElO  core 
memory  buss: 

2)  to  provide  a  paging  mechanism  compati¬ 
ble  with  TENEX; 

3)  to  provide  a  memory  overlap  access  ca¬ 
pability  (streaming  mode)  to  effectively  in¬ 
crease  main  memory  references  when  ap 
plicable, 

The  logic  level  compatibility  problem  is 
defined  as  a  MECL  II  to  the  negative-voltage 
discrete-type  technology  used  in  the  ME10 
memory  boxes,  The  solution  required  the  de¬ 
velopment  of  a  special  circuit  (translator)  to 
drive  the  ME1G  memory  buss.  To  achieve 
minimum  delays  in  accessing  main  memory, 
the  buss  is  divided  into  four  lengths  (see  Fig¬ 
ure  2.5)  and  the  translator  is  optimized  to 
produce  a  14ns  circuit  delay  (see  Figure  2.6). 


The  buss  configuration  yields  a  maximum 
cable  delay  of  35ns  for  a  total  maximum 
delay  of  47ns,  the  latter  within  the  specifica¬ 
tions  required  by  the  streaming  data  transfers. 

The  MLP-900  pager  (see  Figure  27)  is  func¬ 
tionally  identical  to  the  BBN  pager  (TENEX). 
The  paging  task  is  one  of  mapping  the  user’s 
virtual  address  space  into  real  core  memory 
address  within  protected  pages  of  512  words. 
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Figure  2. 5  MPL-900  memory  buso 
block  diagram. 
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Figure  2 . 6  Memory  hues  driver 
schematic. 
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Figure  2.  7  Simplified  diagram  of  ML?  Pager  and  main  memory  interface. 


Thu  pager  is  connected  between  the  MUMKK) 
processor  and  the  MElt)  memory  port.  The 
address  translation  parameters  are  under  con¬ 
trol  of  the  TENEX  system  and  the  parameters 
are  fetched  on  demand  by  the  pager  logic 
from  the  predefined  tables  in  main 
memory  (4).  All  fault  functions  performed  in 
the  BBN  pager  are  performed  by  the;  new 
pager,  including  the  Trap  Status  Word  (TSW) 


which  is  handled  by  TENEX  when  nonrecov- 
erable  faults  occur.  There  are  three  significant 
differences  between  the  implementation  of 
the’  MUMKK)  pager  and  the  BBN  pager: 

1)  the  microcode  of  the  MUMKK)  provides 
the  major  control  functions  when  in  paging 
fault  (see  Figure 

2)  a  transparent  or  real  address  mode  is 
directly  available  to  the;  MUMKK): 
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Figure  2.8  Paging  fault  algorithm 
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3)  the  mapping  process  utilizes  an  address¬ 
able  random  access  memory,  rather  than 
associative  memory  l(x)kup. 

The  first  two  differences  above  are  self- 
explanatory:  the  implementation  of  the  map¬ 
ping  pnx:ess  is  not.  The  20  hit  word  of  the 
translator  memory  is  shown  in  Figure  2.9.  The 
most  significant  9  bits  of  the  Virtual  Address 
Register  (VAR)  are  a  pointer  into  the  page 
memory  whose  contents  contain  an  11  bit 
Real  Core  Address  (RCA).  The  11  bit  RCA  is 
concatenated  with  the  least  significant  9  bits 
of  the  VAR  to  form  a  20  bit  address  for  main 
memory.  (Only  9  hits  of  RCA  are  currently 
implemented  for  an  18  hit  address.)  The  key 
field  is  compared  with  the  contents  of  a  key 
register  (7  bits)  to  determine  the  validity  of 
the  parameters.  The  key  register  is  incre¬ 
mented  for  each  new  user.  Key  register  over¬ 
flow  causes  a  complete  “erasing”  of  the  pager 
memory.  The  microvisor  is  treated  as  another 
user. 

As  part  of  the  main  memory  access,  the 
MLP-900  interface  was  designed  with  a 
streaming  mode.  This  mode  will  allow  over¬ 
lap  memory  operation  to  at  least  three;  levels, 
which  produces  an  effective  memory  speed  of 
3MHz.  The  success  of  this  capability  may 
require  additional  design  effort  within  the 


b'iyurc  2.9  Translator  memory  uord. 


ME10  core  boxes.  This  capability  is  being 
implemented  by  DEC  for  compatibility  of  the 
ME10  with  the  KA10  processor. 

The  streaming  mode  is  designed  to  perform 
block  transfer  of  data  in  and  out  of  main 
memory  with  maximum  memory  overlap. 
The  MElOs  an;  capable  of  four-way  inter¬ 
leave;  successive  memory  requests  can  there¬ 
fore  lx;  initiated  without  waiting  for  the  com¬ 
pletion  of  memory  cycles.  The  MLP-900  oper¬ 
ates  at  a  5MI  Iz.  instruction  rate  (design  goal); 
with  properly  controlled  delays  (memory 
buss,  memory  speed,  and  MLP-900  interval 
buss)  then,  the  memory  requests  can  be  gener¬ 
ated  as  fast  as  MElOs  can  respond  with  ad¬ 
dress  acknowledge  (ADR  ACK)  and  data  is 
transferred  in  synchronism  with  ADR  ACKs 
with  the  appropriate  delays.  The  net  effect  is 
two  separate  pipe  line  operations;  requests  on 
the  control  lines  of  the;  memory  buss,  and  data 
on  the  data  fines  of  the  memory  buss.  The 
MLP-900  is  programmed  to  stop  at  the  end  of 
the  block  transfer  (word  equals  zero),  and 
discard  the  data  remaining  in  the  pipe. 

Mirror isor  State 

The  micro  visor  state  is  synonymous  with 
supervisor,  kernel,  or  monitor  mode  of  other 
CPUs  utilized  for  time  sharing  applications. 
The  microvisor  has  full  access  to  all  MLP-900 
registers  and  instructions,  whereas  the  user  is 
limited  in  his  access  to  protect  the  integrity  of 
the  microvisor.  The  new,  wider  control  mem¬ 
ory  allowed  2  bits  in  each  control  memory 
location  to  be  used  to  determine  whether  mi 
crovisor  mode  is  to  bo  enabled  or  not.  The 
interpretation  of  the  four  possible  codes  is: 
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00  I  iser  Code:  instructions  executed  are  re¬ 
stricted  to  the  user  machine;  subset 


01  Microvisor  Entry  Point:  instructions  exe¬ 
cuted  have  full  microvisor  privileges,  and 
the  user  may  transfer  to  these  locations. 

10  Microvisor  Mode:  same  as  01,  except  the 
user  may  not  transfer  to  these  locations. 

11  Data:  nonexecutable. 

Thirty -six  bit  data  may  now  be  stored  in  the 
new  control  memory.  In  the  c'lginal  STAN¬ 
DARD  design,  control  memory  was  only  32 
bits  wide. 

In  addition  to  protecting  control  memory 
and  privileged  instructions,  the  microvisor 
state  protects  certain  state  flip/flops,  the  in¬ 
terrupt  or  action  request  hardware,  and  I/O 
and  paging  facilities. 

Future  Research  Directions 

As  the  testing  proceeds  to  the  point  of  user 
operation,  th.  design  effort  will  continue  with 
additional  functional  user  capabilities  within 
the  MT.P-900.  These  functions  are  known  as 
language  board  functions.  The  MLP-900  was 
originally  designed  to  provide  a  language 
board  to  minimize  the  control  code  required  to 
emulate  a  specific  processor.  Consideration  is 
being  given  to  generalize  these  functions  to 
achieve  CPU  independence.  This  could  pro¬ 
vide  the  user  with  a  more  flexible  MLP-900 
configuration  for  structuring  main  memory, 
word  size,  interpreting  instructions,  stacking 
operands,  and  a  variety  of  other  functions  still 
to  be  explored. 

SOFTWARE 

The  software  effort  has  been  directed  tow  - 
ards  five  specific  goals: 

1)  design  and  developmen*  of  a  language 
facility  for  the  MLP-900: 
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2)  production  of  diagnostic  programs  for  the 

MLP-900  processor: 

3)  extensions  to  TENEX  to  support  the 

MLP-900; 

4)  development  of  a  microvisor  for  the 

MLP-900: 

5)  design  and  development  of  user  support 

functions  for  the  MLP-900  facility. 

The  first  four  tasks  have  completed  the  design 
phase  and  are  at  various  stages  ot  implemen¬ 
tation.  The  user  support  packages,  which  will 
include  interactive  program  creation,  and  exe¬ 
cution  and  debugging  facilites,  are  in  the 
early  design  phase. 

MLP-900  Language  Facility 

Microprogrammed  computers  are  typically 
characterized  by  small  control  memories  for 
the  storage  of  microprogrammed  routines. 
These  routines  are  used  to  implement  the 
firmware  instruction  set  for  the  target  com¬ 
puter.  The  storage  requirements  and  target 
computer  instruction  execution  time  consider¬ 
ations  bring  pressure  on  the  microprogram  - 
mer  to  make  optimal  use  of  the  microproces¬ 
sor  and  associated  control  memory. 

These  conditions  make  microprogramming 
language  designers  and/or  programmers  tend 
towards  a  one-to-one  cor.espondence  be¬ 
tween  language  statements  and  actual  hard¬ 
ware  microinstructions.  As  a  result,  micropro¬ 
gramming  languages  often  look  like  classic 
assembly  languages  [.'i.fij.  The  General  Purpise 
Microprogramming  Language’  (GPM)  provides 
the  convenience  and  readability  of  a  high- 
level  language  without  preempting  the  flexi¬ 
bility  and  machine  state  control  available  in 
assembly  code  [7 j. 
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The  primary  goal  of  the  GPM  design  was  to 
produce  a  high-level  language  which  did  not 
preclude  any  coding  options.  In  particular,  as 
GPM  was  to  lx?  the  primary  language  for  the 
MLP-9(Xf.  every  control  memory  code  had  to 
be  possible  as  language  output.  The  language 
had  to  be  amenable  to  diagnostic,  program¬ 
mers,  application  programmers,  and  research¬ 
ers.  This  was  accomplished  by  combining  the 
appropriate  features  of  assembly  code  with 
the  complimentary  high-level  features. 

This  goal  was  achieved  by  designing  a  lan¬ 
guage  with  careful  consideration  of  the  hard¬ 
ware  instruction  set.  The  language  was  con¬ 
strained  not  to  implicitly  affect  the  machine 
state  at  runtime.  These  considerations  pro¬ 
vided  freedom  and  low-level  control  for  the 
programmer.  The  compiler  needed  some  flex¬ 
ibility  to  allow  tor  high-level  language  forms. 
This  flexibility  was  provided  by  allowing  the 
language  to  produce  several  microinstructions 
for  each  language  statement. 

GPM  is  complete  and  preliminary  docu¬ 
mentation  is  available.  All  MLP-900  coding  is 
being  done  in  GPM. 

Some  GPM  statemencs  look  very  much  like 
assembly  language.  These  statements  corre¬ 
spond  to  the  I/O  instructions.  The  high-level 
statements  fall  into  four  categories  of  interest: 

1)  syntactic  block  structure; 

Z)  hardware  generalization: 

d)  multi  instruction  statements; 

4)  expressions. 

Svuiariir  Work  Slrut  luri'. 

Th*  low  level  constraints  in  the  GPM  de¬ 
sign  precluded  the  implementation  of  any 
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dynamic  storage  allocation,  or  even  of  an  op¬ 
erand  stack.  As  a  result,  the  block  structuring 
in  GPM  may  be  considered  to  be  a  compile - 
time  artifact.  None  the  less,  by  using  the  block 
structure  syntax  in  a  most  rudimentary  way, 
the  resulting  language  has  heen  rendered 
more  tractable  and  comprehensib'e. 

The  user  may  rename  any  memory  cell  at 
the  top  of  a  block.  Any  synonym  defined  at 
the  start  of  a  block  is  undefined  at  the  end  of 
the  block.  This  allows  procedures  to  give 
mnemonic  names  to  parameters  and  tempo¬ 
rary  registers.  Additionally,  the  practice  of 
declaring  registers  at  the  top  of  a  block  ren¬ 
ders  the  hlock’s  scope  instantly  apparent.  This 
block-structured  synonym  facility,  if  ex¬ 
ploited  properly,  can  produce  more  readable 
programs. 

Control  stntrnn-nts.  The  block  structure 
syntax  is  used  to  define  the  scope  of  IF  and 
DO  statements.  The  DO  statement  heads  a 
block  which  will  be  iterated  upon  indefinitely. 
The  method  of  exiting  a  DO  block  is  the 
BREAK  statement. 

The  above  examples  of  applications  of 
block  structure  syntax  demonstrate  how  the 
concept  can  be  useful  >n  a  semantically  sim¬ 
ple  language.  One  could  even  restate  the  GPM 
design  goal:  design  a  language  which  is  syn 
tactically  rich  and  semantically  poor. 

Ill i  ril n  o  re  I.ViU'rn  liznlion. 

One  of  the  more  classic  functions  of  a  pro¬ 
gramming  language  is  to  provide  a  complete 
set  of  functions,  where  the  hardware  may  not. 
For  instance,  on  a  computer  with  only  a  jump 
on  less  lb. m  zero,  the  programming  language 
would  provide  all  eight  possible  jumps  rela 
live  to  zero.  GPM  attempts  to  do  this  in  all 
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cases  where  it  is  possible,  without  violating 
the  design  constraints. 

This  type  of  language  feature  allows  the 
programmer  to  ignore  some  of  the  intricacies 
of  the  hardware.  However,  if  a  GPM  pro¬ 
grammer  wishes,  he  may  stick  to  the  GPM 
subset  which  corresponds  to  the  hardware 
MLP-900  instructions. 

Multi-  instruction  Storemen  ts. 

Some  GPM  statements  will  always  compile 
into  several  hardware  MLP-900  instructions. 
These  are  common  functions  with  which  the 
user  should  not  have  to  concern  himself. 

In  order  to  transfer  data  from  the  operating 
engine  to  the  control  engine,  the  Exchange 
Buss  (XBUS)  is  used.  This  requires  an  OE-GE 
instruction  pair  to  be  executed  in  parallel, 
each  instruction  moving  information  to  or 
from  the  XBUS  and  internal  registers.  There¬ 
fore,  all  interengine  assignments  require  the 
generation  of  two  instructions. 

The  GPM  statement 

CEO  -  RO ; 
will  compile  into* 

XBUS  -  RO  : 

CEO  -  XBUS  ; 

These  multi -instruction  generating  state¬ 
ments  make  programs  shorter  and  thus  easier 
to  read.  The  information  not  explicitly  stated 
is  essentially  redundant  in  the  above  example. 
Thus,  brevity  is  achieved  without  the  intro¬ 
duction  of  obscurity. 


*  As  CI’M  is  I  hr  primary  Ml.P-900  langiingi:.  it  compiles  into 
the  subset  of  itself  which  c.oirespomls  to  actual  hardware 
instructions. 
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Expressions. 

Expressions  are  so  common  in  high-level 
languages,  it  might  seem  out  of  place  to  de¬ 
vote  space  to  them  here.  However,  the  con¬ 
straints  on  the  GPM  design  complicate  the 
compilation  •'f  expressions.  GPM  is  not  al¬ 
lowed  to  make  any  implicit  changes  to  the 
machine  state  at  runtime.  This  precludes  the 
introduction  of  temporaries  to  evaluate  ex¬ 
pressions.  Two  brief  examples  will  demon¬ 
strate  bow  expressions  are  to  be  handled. 

Arithmetic  expressions.  The  GPM  Statement 
RO  -  RO  AND  Rl  +  R2  ; 
will  compile  into 

RO  -  RO  AND  Rl  ; 

RO  RO  +  R2  ; 

However  the  GPM  statement 
RO  -  RO  AND  (Rl  +  R2)  ; 

will  not  compile,  for  lack  of  a  temporary  for 
(Rl  +  R2). 

Boolean  expressions.  The  GPM  Statement 
FO  -  (FI  AND  F2)  or  (F3  AND  F4)  ; 
will  compile  into 

IF  FI  AND  F2  THEN  GOTO  +3  ; 

IF  F3  AND  F4  THEN  GOTO  +2  ; 

IF  NOT  (FO  -  FALSE)  THEN  GOTO  +2  ; 

FO  -  TRUE  ; 

Boolean  expressions  will  always  compile  as 
the  program  counter  can  be  used  as  a  tempo¬ 
rary  Boolean  value.  The  expression  evaluation 
in  GPM  leaves  much  to  be  dpsired,  but  it  was 
felt  that  when  the  expressions  worked,  they 
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were  so  superior  to  the  assembly  code  alter¬ 
native  that  they  would  be  included  in  spite  of 
themselves. 

Diagnostic  Programs 

The  main  thrust  of  the  diagnostic  task  has 
been  to  convert  the  STANDARD  Computer 
Corporation  assembly  language  diagnostics 
into  GPM.  Diagnostics  have  also  been  neces¬ 
sary  for  the  new  facilities  added  to  the  MLP- 
900  by  the  hardware  group.  These  include 
both  the  microvisor  protection  facilities  and 
the  PDP-10  memory  and  I/O  buss  interlaces. 

The  production  of  the  complete  diagnostic 
system  for  the  MLP-900  requires  three  tasks 
to  be  completed: 

1)  conversion  of  STANDARD  assembly 
language  diagnostics  into  GPM: 

2)  creation  of  new  diagnostics  for  new 
hardware  facilities:  and 

3)  development  of  a  diagnostic  supervisor  to 
load  and  run  the  diagnostics. 

Conversion  of  Existing  Diagnostics. 

The  conversion  of  the  STANDARD  diag¬ 
nostics  into  GPM  took  several  steps: 

1)  the  diagnostics  were  assembled  on  the 
STANDARD  assembler  on  the  1C -4000: 

2)  the  assembly  output  on  7 -track  magnetic 
tape  was  moved  to  the  PDP-10: 

3)  the  hexadecimal  code  was  exti  cted  from 
the  output  file,  converted  to  octal,  :>d  the 
octal  was  converted  to  GPM: 

4)  the  new  GPM  source  statements  were 
inserted  into  the  existing  source  file  to  re¬ 
place1  the  old  STANDARD  assembly  lan¬ 
guage  statements: 


5)  the  new  diagnostics  were  compiled  in 

GPM. 

This  process  gave  the  PRIM  project  a  readable 
set  of  basic  processor  diagnostics.  The  conver¬ 
sion  process  was  easier  to  develop  than  re¬ 
writing  the  8,000  lines  of  STANDARD  diag¬ 
nostics  by  hand. 

Veil  Diagnostics. 

The  new'  diagnostics  are  being  produced  in 
GPM.  The  highest  priority  new  diagnostics 
will  he  the  I/O  buss  ones,  as  no  user  may  -se 
the  MLP-900  until  the  I/O  buss  interface  is 
checked  out. 

Diagnostic  Supervisor. 

Two  diagnostic  supervisors  are  under  de¬ 
velopment.  The  first,  which  has  been  in  use 
for  several  months,  is  the  I/O  buss  simulator 
system.  The  system  uses  the  I/O  buss  simula¬ 
tor  over  a  teletype  line.  This  allows  commu¬ 
nication  with  the  PDP-10  without  looking 
directly  to  the  PDP-10  I/O  buss.  This  enabled 
checkout  to  begin  on  the  MLP-900  before  the 
final  checkout  of  the  I/O  buss  interface. 

The  newr  diagnostic  supervisor  will  use  the 
real  I/O  and  the  new  TENEX  system  call 
discussed  below. 

TEX  EX  System  Changes 

To  maintain  reliability  and  continuity  in 
the  existing  TENEX  service,  changes  to  the 
TENEX  operating  system  core  are  being  kept 
to  a  minimum.  The  PRIM  project  has  designed 
one  TENEX  system  call  to  enable  a  privileged 
user  program  direct  access  to  the  MLP  (see 
Figure  2.10). 

Microrisor 

A  microvisor  has  been  designed  to  commu¬ 
nicate  with  privileged  user  programs.  This 
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Returns ? 

♦1  Error  -  error  code  I n  Ac  1 
+2  Successful 
INPUT  RESULT 

Ac  1  Ac  2  AC  3 

Mode  0  0  Assign  MLP  -  Map  MLP  core  starting  at  500000 

Error  return  If  MLP  not  available 
Return  page  count  I n  Ac  i 
Modes? 

1  Input  M  on  interrupt 

2  Do  nothing  on  Interrupt 

0  -1  -1  Status  MLP  -  Returns? 

Ac  1?  CONI  DEVA,1  (last  interrupt  DEVA) 
Ac  2?  0ATAI  DEVA, 2  (last  interrupt  DEVA) 
Ac  3?  CONI  D£VB,3  (last  Interrupt  DEVB) 
Ac  4?  DATAI  DEVB, 4  (last  interrupt  DEVB) 
0  Code  Data  Output  to  MLP 
Code? 

B35  ON 

834  O-CONO  1 -DAT AO 

B33  0-DEVA  1-DEVB 

832  0-Return  Immediately 

1-Wait  for  MLP  interrupt 
000  Status  MLP  -  Returns? 

Ac  1?  Interrupt  Count  (DEVA) 

Ac  2?  Interrupt  Count  (DEVB) 

-100  Release  MLP  -  This  is  called  by  RESET 


Figure  2.10  MLP  J5YS  (TENEX  system  call ). 


Microrisor. 

The  target  microvisor: 

1)  will  handle  page  faults  in  order  to  allow 
for  demand  paging  of  the  target  address 
space; 

?.)  will  support  I/O  requests  from  MLP -900 
user  programs  to  TENEX;  and 

3)  will  contain  the  necessary  hooks  for  the 
debugging  system. 


microvisor  initially  will  have  only  two  func¬ 
tions:  to  load  context  into  the  MLP -900 
processor,  and  to  dump  processor  context  into 
the  POP -10  core  memory. 

Future  Research  Directions 

Two  areas  remain  for  the  completion  01  ihe 
MLP-900  program  facility:  a  more  sophisti¬ 
cated  microvisor,  and  a  user  support  facility. 
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I  ner  Support  Fwilitv. 

The  user  support  facility  will  first  provide 
a  convenient  debugging  environment  for 
MLP-900  programs.  Once  produced,  it  will  be 
necessary  to  support  MLP-900  programs  in 
several  con  figuration.  A  partial  list  of  possi¬ 
ble  configurations  include  the  MLP  as  a 
subroutine  (function  hox)  to  a  POP-10,  the 
MLP  running  in  parallel  to  a  PDP-10  user 
program,  and  the  MLP  using  the  PDP-10  as 
memory. 

Upon  completion  of  the  PRIM  facility,  there 
are  essentially  two  areas  in  which  the  PRIM 
project  expects  to  continue.  The  first  is  in  the 
development  of  a  facility  for  high  level  lan¬ 
guage  interpretation.  It  has  heen  shown  by 
the  1)1700  group  at  Burroughs -Goleta  and  in 
several  other  studies  that  interpreting  high- 
level  languages  can  produce  far  more  signifi¬ 
cant  computational  efficiencies  than  simple 
emulation  of  existing  hardware.  Along  this 
line,  two  specific  proposals  are  being  consid¬ 
ered:  a  Lisp  execution  engine  based  on  Peter 
Deutsch’s  wo! '  at  Xerox -Palo  Alto  Research 
l tenter  in  support  of  the  Automatic  Program¬ 
ming  project:  or  a  Pascal  execution  engine  in 
support  of  the  Computer  Software  Assurance 
project. 

The  second  area,  and  of  no  less  import,  is 
the  interaction  with  and  support  lor  ARl'A 
Network  users  who  may  avail  themselves  of 
tb(>  PRIM  facility.  We  hop*  that  the  unique 
facility  being  provided  through  the  effort  of 
the  PRIM  project  will  lx.1  useful  not  only  to 
ISI.  hut  also  to  other  governmental  contractors 
throughout  the  ARPANET. 


.M LP-9U0  l  ser  Programming  Facility. 

The  design  and  development  of  a  high- 
level  programming  language  are  considered 
the  first  of  two  minimum  requirements  for 
efficient  user  utilization  of  the  MLr'-900.  The 
second  requirement  is  for  a  symbolic  debug¬ 
ging  facility  of  sufficient  power  to  allow  a 
user  of  moderate  experience  the  ability  to 
meaningfully  breakpoint  and  patch  MLP  pro¬ 
grams. 

The  debugging  mechanism  is  being  studied 
in  parallel  with  the  current  ongoing  hardware 
development.  It  is  expected  to  capitalize  heav¬ 
ily  on  the  experience  gained  during  the  inte¬ 
gration  of  the  MLP/PDP-10  system.  The  early 
phase  will  rely  on  a  modified  version  of  a 
currently  available  DDT  that  is  a  TENEX 
system  programming  tcxil. 

Considerable  attention  will  be  paid  to  ac¬ 
quiring  interna!  measurements  of  system  per¬ 
formance  as  modifications  are  made  to  the 
scheduling  and  core  managing  algorithms. 
Both  KA10  and  MLP  performance  will  he 
monitored.  Modifications  designed  to  improve 
performance  will  be  investigated  and  verified 
by  measurement  under  controlled  and  non- 
eon  trolled  loading,.  It  is  considered  desirable  lo 
monitor  and  verily  overaii  system  evolution 
through  direct  measurement.  A  user-inode 
statistics  gathering  and  analysis  package  will 
be  developed  to  provide  an  adequate  por¬ 
trayal  of  system  performance. 
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INTRODUCTION 

ISI’s  work  on  automatic  programming  has 
centered  on  three  main  activities.  First,  we 
worked  with  ARPA  to  help  establish  the  di¬ 
rection  and  scope  of  the  ARPA  program  in 
automatic  programming.  Towards  this  end, 
discussions  were  held  with  most  of  the  prom¬ 
inent  people  in  the  community,  both  ARPA 
and  non -ARPA  contractors,  and  their  views 
were  solicited  on  the  current  state  of  the  art 
and  the  direction  future  research  should  take. 
These  view's  were  integrated  w'ith  our  per¬ 
ception  of  the  field  to  form  a  coherent  picture 
and  approach  to  automatic  programming. 
These  findings  were  presented  in  a  report  [1] 
which  was  sent  to  all  those  participating  in 
the  study.  It  was  the  subject  of  numerous 
discussions  around  the  country,  and  acted  as  a 
straw  man  for  an  ARPA  approach  to  auto¬ 
matic  programming  in  two  meetings  of  the 
community  w’hich  were  held  to  arrive  at  a 
consensus  view. 

Second,  we  have  developed  a  language- 
mdependent  interface  between  a  user  and  his 
programming  language  which  makes  availa¬ 
ble  to  him  the  programming  environment  of 
Bolt  Beranek  and  Newman's  (BBN)  LISP.  This 
is  a  significant  advancement  which  enables 


users  of  a  wide  variety  of  programming  lan¬ 
guages  to  use  a  powerful,  common,  well -engi¬ 
neered  environment  for  programming.  Fur¬ 
thermore,  the  interface  has  spurred  the  credi¬ 
bility  of  our  revised  proposal  for  ARPA’s 
national  program:  namely,  the  creation  of  a 
facility  for  software  production  which  will 
contain  a  common  set  of  tools  available  to 
users  of  different  languages  running  on  dif¬ 
ferent  machines.  This  facility  witl  utilize  the 
ARPANET  to  establish  communication  be¬ 
tween  tools  running  on  diverse  machines,  and 
will  focus  attention  on  the  tools  needed  to 
increase  productivity  and  the  technology 
needed  to  effectively  integrate  them  into  a 
well -engineered  system. 

Third,  formulative  work  has  continued  in 
the  comprehension  of  human  dialogue  and 
the  extraction  of  knowledge  of  new  problem 
areas  from  their  descriptions.  We  thus  are 
investigating  the  possibility  of  domain -inde¬ 
pendent  systems  which  can  be  taught  (by  an 
expert  in  that  area)  about  new  domains  in 
terms  of  the  objects  which  exist  in  that  do¬ 
main,  the  relationships  between  these  objects, 
the  transformations  which  can  occur  within 
the  domain,  and  the  constraints  which  must 
lx?  satisfied.  This  knowledge  will  then  be  used 
to  transform  procedurally -specified  tasks 
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within  the  domain  into  efficient  computer 
programs  which  perform  these  tasks.  The  im¬ 
portance  of  this  effort  lies  in  the  attempt  to 
build  a  computer  system  which  learns  about 
new  areas  of  competence  in  terms  appropriate 
to  that  domain,  and  uses  this  knowledge  to  fill 
in  the  details  of  a  high-level  procedural  spec¬ 
ification  for  a  task  in  that  domain. 


As  presented  in  the  report  [1],  the  goal  of 
automatic  programming  is  simply  the  effec¬ 
tive  utilization  of  computers,  which  implies 
both  simplicity  of  use  and  efficient  applica¬ 
tion  of  computing  resources.  Thjs,  automatic 
programming  is  the  application  of  a  comput¬ 
ing  system  to  the  problem  of  effectively  uti¬ 
lizing  that  or  another  computing  system  in 
the  performance  of  a  task  specified  hy  the 
user.  Although  this  is  certainly  what  is  meant 
by  automatic  programming,  this  definition 
does  little  to  restrict  the  set  of  applicable 
computer  systems  included  in  the  automatic 
programming  domain. 

We  therefore  chose  to  restrict  the  definition 
hy  emphasizing  the  use  (if  such  systems  by 
those  who  are  not  professional  programmers. 
This  emphasis  necessitates  the  use  of  less 
precise  and  more  problem -oriented  descrip¬ 
tions  of  the  computing  task,  and  increases  the 
amount  of  translation  required  from  the  sys¬ 
tem  to  tuin  such  specifications  into  efficient 
programs. 

Problem -ori en  led  Mode! 

Towards  this  end,  we  conjecture  that  the 
solution  of  every  computable  problem  can  bo 
represented  entirely  in  problem -domain 
terms  as  a  sequence  (which  may  involve  loops 


and  conditionals)  of  actions  in  that  domain 
which  affect  a  data  base  of  relationships  be¬ 
tween  the  entities  of  the  domain.  Included, 
either  as  part  of  the  data  base  or  as  a  separate 
part  of  the  model,  is  the  history  of  the  model 
(i.e.,  the  sequence  of  actions  applied  to  the 
model).  This  logically  completes  the  model 
and  enables  questions  or  actions  involving 
historical  information  to  be  handled.  In  a 
strong  sense,  such  a  solution  is  a  direct  simu¬ 
lation  of  the  domain.  The  system  models  at 
each  step  what  would  occur  in  the  domain. 

The  important  part  of  the  above  conjecture 
is  that  any  computable  problem  can  he  solved, 
thence  described,  in  problem -domain  terms. 
The  solution,  then  can  be  divided  into  two 
parts:  an  external  and  an  internal  part.  The 
external  part  is  the  problem  specification 
given  by  the  user  in  completely  domain -spe¬ 
cific  terms.  The  requirement  ror  such  users  is 
no  longer  a  comprehensive  knowledge  of 
computers,  but  rather  the  ability  to  com¬ 
pletely  characterize  the  relevant  relationships 
between  entities  of  the  problem  domain  and 
the  actions  in  that  domain.  In  addition,  such 
users  should  have  a  rough  awareness  of  the 
problem-solving  capability  of  the  system  so 
that  they  can  provide  additional  help  where 
needed  in  the  form  of  more  appropriate  ma¬ 
cro-actions,  recommendations  about  the  use  of 
certain  actions,  and/or  imperative  sequences 
which  will  solve  part  or  all  of  the  problem  in 
problem -related  terms. 

The  internal  part  is  first  concerned  with 
finding  a  solution  in  problem -related  terms,  if 
this  has  not  already  been  provided  by  the 
user.  Second,  this  part  is  concerned  with 
finding  efficient  solutions  given  the  available 
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computing  resources.  Such  optimizations  oc¬ 
cur  at  two  levels  beyond  what  is  normally 
considered  optimization.  First,  at  the  problem 
level,  recognition  that  certain  entities  and/or 
relationships  are  irrelevant  enables  their  re¬ 
moval  from  the  model.  Second,  since  only  part 
of  the  state  of  the  modeled  domain  is  re¬ 
quired,  and  only  at  certain  points  in  the  solu¬ 
tion  process,  rather  than  simulating  the  model 
completely  at  each  step,  the  system  can  em¬ 
ploy  alternative  representations  which  re¬ 
quire  less  maintenance  and  which  either  di¬ 
rectly  mirror  the  required  part  of  the  domain 
state  or  allow  such  parts  to  be  computatio¬ 
nally  inferred.  Such  representations  may  also 
enable  more  direct  solution  of  the  problem.  It 
is  these  optimizations  which  form  the  main 
distinction  between  the  code -generation  part 
of  an  automatic  programming  system  and 
current  state  of  the  art  compilers. 

Thus,  the  definition  of  an  automatic  pro¬ 
gramming  system  is  one  which  accepts  a 
problem  in  terms  of  a  complete  model  of  the 
domain,  which  obtains  a  solution  for  the 
problem  in  terms  of  this  model,  and  which 
produces  an  efficient  computer  implementa¬ 
tion  of  this  solution  in  the  form  of  a  program. 

OTHER  APPROACHES 

Unfortunately,  this  view  did  net  represent 
a  consensus  of  the  automatic  programming 
community.  Three  divergent  approaches  to 
tha  problem  (see  below)  emerged  from  the 
two  meetings  held  to  discuss  these  issues. 

A  ii Inina  tic  Programming  Focus 

The  first  meeting  started  with  a  broad  dis¬ 
cussion  of  automatic  programming  and  what 
it  covered.  The  general  feeling  appeared  to  be 
that  automatic  programming,  as  defined  in 


the  report  [l],  was  too  broad  and  covered  too 
much  ground.  Because  of  this,  discourse  be¬ 
tween  the  different  disciplines  involved 
would  be  difficult,  if  not  impossible.  It  was, 
however,  suggested  that  automatic  program¬ 
ming  was  a  good  organizational  device  to 
focus  attenMon  on  a  common  goal.  That  goal 
is  increasing  the  accessibility  of  computers  to 
users,  especially  to  nonprofessional  computer 
users. 

\onprofessional  I  'sets. 

Although  it  was  difficult  to  describe  the 
nonprofessional  users  (e.g.,  whether  or  not 
th  iy  possessed  procedural  knowledge),  it  was 
generally  agreed  that  their  main  attribute  was 
that  they  would  be  working  with  the  system 
through  a  model.  Hence,  the  whole  notion  of 
modeling  appears  to  be  at  the  very  core  of 
automatic  programming.  The  ease  with  which 
users  can  express  their  tasks  in  terms  of  the 
model,  their  ability  to  view  the  system  s  ac¬ 
tions  in  terms  of  this  model,  and  the  ability  to 
define,  modify,  and  enhance  models  will  be 
critical  issues  in  automatic  programming  sys¬ 
tems. 

It  was  pointed  out  that  the  term  complete 
model,  as  defined  in  the  report,  was  unfortu¬ 
nate.  for  although  the  behavior  of  the  user's 
task  could  be  completely  described  in  terms  of 
this  model,  the  model  itself  must  be  treated 
by  the  automatic,  programming  system  as  in¬ 
complete  and  dynamically  subject  to  change 
by  the  user  during  the  course  of  his  problem 
specification. 

Further  attempts  to  describe  the  nonprofes¬ 
sional  users  yielded  the  conclusion  thai  there 
were  at  least  two  classes  of  such  users.  First, 
there  are  the  experts  in  the  field  who  would 
define  basic  imxlels  applicable;  to  that  field. 
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and  build  up  within  the  system  a  large  body 
of  knowledge  in  suitable  form.  In  a  sense, 
they  are  more  constructors  of  systems  than 
end  users.  The  second  class,  end  users  of  such 
systems,  would  either  parametrically  use  the 
supplied  models  or  would  'modify  and  en¬ 
hance  these  models  tor  specialized  usage.  It 
was  generally  agreed  that  were  a  suitable 
automatic  programming  system  available,  ex  - 
perts  in  wide  varieties  of  fields  would  be 
more  than  willing  to  devote  their  energy  tow¬ 
ards  building  the  basic  models  for  that  field. 

Discussion  now  relumed  to  describing  au¬ 
tomatic  programming  itself,  and  it  was 
brought  out  that  the  report  was  very  heavily 
biased  toward  discussion  of  the  system  as  if  it 
were  well-defined  thing.  Rather,  it  is  a  re¬ 
search  domain,  one  that  is  difficult  to  define. 
At  this  point  it  was  mentioned  that  specific 
systems  of  the  type  envisioned  were  being 
built  or  already  existed.  As  such,  what  was 
the  new  research  area?  Surely  it  was  not 
further  systems  of  this  type  themselves. 
Rather,  automatic  programming  is  the  meth¬ 
odology  of  building  such  systems.  That  is,  the 
automatic  development  of  special  purpose 
systems. 

Three  Approaches 

At  this  point,  one  of  the  key  considerations 
emerged.  Part  of  the  trouble  in  discussing 
automatic  programming  systems  was  that 
different  approaches  to  the  problem  were  be¬ 
ing  discussed.  There  appeared  to  be  three 
rather  distinct  approaches  to  the  problem, 
which  are  called  the  low,  medium,  and  high 
roads.  These  three  approaches  factor  nicoiy  as 
to  the  amount  of  involvement  of  models,  the 
technology  upon  which  they  defiend,  and  the 
time  scale  required  for  their  development. 
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The  low  road  is  the  most  imminent  and  the 
one  most  closely  associated  with  computer 
science.  It  is  based  on  the  paradigm  that  au¬ 
tomating  programming  is  best  done  by  pro¬ 
viding  the  programmer  with  tools  that  en¬ 
hance  his  capabilities.  These  tools  are  of  three 
basic  types.  The  first  is  high-level  languages 
which  enable  him  to  describe  his  problems  in 
more  appropriate  terms  and  reduce  the 
amount  of  translation  he  must  perform.  It 
includes  language  development  at  both  the 
control  and  data  level,  and  library  systems 
which  enable  the  programmer  to  assemble  his 
system  from  prepackaged  modules.  A  second 
major  tool  is  optimization  -  global  optimiza¬ 
tions  which  would  allow  the  programmer  to 
utilize  these  high-level  languages  and  pre¬ 
packaged  modules  without  concern  for  effi¬ 
ciency,  with  the  knowledge  that  they  can 
later  be  automatically  optimized.  These  opti¬ 
mizations  include  and  critically  depend  upon 
the  system’s  choice  of  data  structures  and/or 
processing  algorithms,  rather  than  low-level 
issues  such  as  register  usage  or  common  sub¬ 
expression  elimination.  The  third  major  tool 
involves  improving  the  programming  envi¬ 
ronment  available  to  users.  This  includes  au¬ 
tomatic  correction  of  user  errors,  aids  for  de¬ 
bugging  and  testing  user  programs,  mecha¬ 
nisms  for  maintaining  the  consistency  of 
source  and  object  programs,  means  for  propa¬ 
gating  changes  throughout  a  program,  and 
various  other  bookkeeping  mechanisms  re¬ 
lated  to  the  programming  effort. 

Midilh'  Hood. 

The  middle  road  is  mainly  concerned  with 
exploiting  a  model  that  has  been  prewired 
into  the  system  for  use  iri  a  specialized  area. 
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and  with  integrating  existing  technology  from 
both  artificial  intelligence  and  the  low  road  in 
construction  of  a  coherent  system.  It  is  thus 
characterized  by  its  deep  involvement  with  a 
particular  application  area,  its  exploitation  of 
a  prespecified  model,  and  its  usage  by 
non  programmers.  These  systems  tend  to  be 
large,  embodying  thousands  of  facts  and  rela¬ 
tions  about  the  application  area.  They  tend 
also  to  work  in  very  narrow  areas  and  utilize 
special  processing  techniques  which  enable 
them  to  optimize  all  or  part  of  the  processing 
specified  within  that  domain.  In  performance 
they  tend  to  exceed  average  human  compe¬ 
tence  but  are,  as  yet,  unable  to  match  expert 
ability. 

High  Road. 

The  third  and  most  remote  approach  is  the 
high  road.  Its  basic  concern  is  with  the  dy¬ 
namic  acquisition  of  modeis  for  the  user’s 
application.  As  such,  its  performance  of  tasks 
within  the  user’s  domain  must  rely  on  its 
ability  to  utilize  domain -dependent  knowl¬ 
edge  of  unknown  form  contained  within 
these  models.  Thus,  it  is  concerned  with  the 
space  of  possible  models,  with  understanding 
the  interactions  between  parts  of  these  mod¬ 
els,  with  the  ability  vO  recognize  incomplete¬ 
ness  and  inconsistency  within  the  models, 
and  the  ability  to  perceive  and  utilize  causal 
relationships  to  achieve  a  goal  within  these 
models,  h  is  also  concerned  with  how  these 
models  can  he  communicated  hetween  the 
users  or  experts  who  understand  the  area  and 
the  system  itself.  Besides  the  technologies  be¬ 
ing  developed  in  the  low  and  middle  road 
approaches,  it  is  clear  that  the  high  road  ap¬ 
proach  also  requires  major  breakthroughs  in 


artificial  intelligence,  modeling  techniques, 
and  communications  technology. 

Using  the  above  conceptualization,  the  fol¬ 
lowing  categorization  of  ongoing  work  re¬ 
sulted.  (See  Figure  3.1.)  The  approaches  are 
shown  in  terms  of  the  high,  medium  and  low 
roads  versus  the  specificity  of  the  system.  The 
indentation  in  the  medium  approach  indicates 
that  it  is,  by  its  nature,  an  approach  at  specific 
systems  or  specific  classes  of  systems. 

Theoretical  Approach. 

It  was  mentioned  almost  in  passing  in  the 
meetings  that  the  theoretical  level  was  per¬ 
haps  orthogonal  to  the  issues  discussed  above, 
i.  e„  correctness  is  necessary  at  all  levels.  It 
was  also  stated  that  the  theoretical  approach 
was  getting  much  more  practical  via  verifi¬ 
cation  work,  formal  semantics,  and  theory  of 
programming.  In  fact,  practical  verification 
can  be  seen  as  an  extension  of  compiler  tech¬ 
nology.  Certainly  the  case  for  the  importance 
of  the  theoretical  approach  in  automatic  pro¬ 
gramming  research  was  not  clearly  made  and 
was  a  topic  at  the  second  meeting. 

Problems  Within  Each  Approach 

The  last  major  area  covered  was  the  prob¬ 
lems  which  had  to  be  solved  for  the  different 
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approaches  to  attain  an  automatic  program¬ 
ming  system.  As  presented,  the  problems 
overlapped  quite  a  bit  and  do  not  reflect  the 
distinct  areas  of  concern  that  seem  to  be  ap¬ 
parent  in  the  above  conceptualization;  there¬ 
fore,  they  have  been  rearranged  and  modified 
to  place  them  in  this  framework. 

Ijoic  Road  Problems. 

The  low  road  approach  has  the  following 
prohlems: 

1)  the  move  from  essentially  macro-based 
languages  to  essentially  context-dependent 
ones; 

2)  incorporation  of  understood  concepts  (e.g, 
error  handling,  flexibility,  modification)  into 
new  or  existing  systems; 

3)  data  representation  and  its  interdepen¬ 
dence  with  procedures; 

4)  the  software  factory,  including  both 
module  selection  and  interface  matching; 

5)  representation  theory,  including  what  the 
representation  is  really  being  used  for,  what 
is  it  accidentally  being  used  for,  and  what 
pertubations  can  be  made  to  it  without  af¬ 
fecting  it’s  real  use; 

6)  global  program  manipulation  trade  offs: 

7)  optimization,  including  the  dropping  of 
irrelevancies,  representational  abstraction, 
and  computer -resource  allocation. 

Middle  Road  Problems. 

For  the  middle  road  approach,  the  follow¬ 
ing  problems  exist: 

1)  the  implementation,  use,  and  evolution  of 
asynchronous  strategy -directed  models,  in¬ 
cluding  the  study  of  demon  interactions 
and  language  for  the.  domain -dependent 
and  domain -independent  strategies; 


2)  understanding  the  nature  of  the  applica¬ 
tion  area  and  finding  ways  to  encase  it  in 
computable  form. 

Middle  and  High  Road  Problems. 

The  following  are  problems  that  relate  to 
both  the  middle  and  high  road  approaches: 

1)  domain  definition  and  handling  of  ex¬ 
ceptions  within  the  problem  statement; 

2)  optimization  at  the  model  level; 

3)  model  viewing; 

4)  responsibility  assessments. 

High  Rond  Problems. 

For  the  high  road  approach  the  problems 

are: 

1)  communications  technology,  including 
the  ordering  of  information  for  presenta¬ 
tion,  the  establishment  and  use  of  context, 
the  effect  of  the  recipient’s  capabilities  on 
communication,  and  the  perception  of  the 
recipient’s  capabilities  hy  the  speaker; 

2)  modeling  technology,  including  space  of 
possible  models,  understanding  the  interac¬ 
tion  between  parts  of  a  model,  ability  to 
recognize  a  model’s  incompleteness  and  in¬ 
consistencies,  and  the  ahility  to  perceive 
and  utilize  causal  relationships  to  achieve  a 
goal. 

( lorn  m  on  l\-sho  red  I  * rohlem  s. 

There  appear  to  lie  two  problems  that  relate 
to  all  the  levels.  They  are: 

1)  maintenance  problems  for  long-life  sys¬ 
tems.  including  machinable  documentation, 
modification  of  the  system's  function,  and 
maintenance  of  the  system's  function  as  the 
environment  changes; 
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2)  movement  between  levels  in  terms  of 

both  debugging  and  documentation. 

Theoretical  Approach  Problems. 

Finally,  there  are  a  set  of  problems  which 
deal  with  the  theoretical  approach.  They  are: 

1)  axiomization  uf  complex  data  structures; 

2)  structuring  of  a  program  for  verification; 

3)  more  facts  on  low-level  complexity  the¬ 
ory; 

4)  the  ability  to  prove  numerical  results 

within  a  range. 

Report  anti  Meeting  Summation 

The  three  distinct  approaches  to  automatic 
programming  form  a  nice  covering  of  the  field 
in  that  they  are  nested  so  the  results  of  one 
should  be  available  to  those  at  a  higher  level. 
And  although  the  low  and  high  roads  are 
largely  fragmentary  studies  aimed  at  solving 
particular  problems  within  those  approaches, 
the  middle  course  is  primarily  the  practical 
systems  approach  which  should  push  the 
methodologies  on  either  side  of  it. 

There  were  two  main  criticisms  of  the 
views  expressed  in  the  report  |1).  First,  it  is 
too  ambitious.  The  goal  of  domain -indepen¬ 
dent  usage  by  those  who  are  noi  professional 
programmers  is  unattainable  within  a  time 
period  appropriate  for  an  ARPA  project.  Sec¬ 
ond,  this  emphasis  and  the  way  that  the  re¬ 
port  was  written  limit  the  work  that  could  go 
on  under  the  other  approaches  which  their 
proponents  feel  have  a  higher  probability  of 
success  within  an  appropriate  time  frame. 

LA  NG  UA  G  E-  IX  DEPENDENT 
PROGRA  MMER  INTERFA  CE 

In  view  of  the  above  concerns,  we  have 
very  recently  lx:gun  to  explore  a  low  road 


approach  based  on  the  creation  of  a  facility 
for  software  production  by  professional  pro¬ 
grammers  utilizing  tools  created  on  separate 
machines,  but  operating  within  a  common 
framework  via  the  ARPA  Network.  Such  an 
approach  has  the  advantage  that  some  of  the 
tools  necessary  for  effective  software  produc¬ 
tion  already  exist,  but  not  in  a  common  envi¬ 
ronment  where  they  can  be  effectively  em¬ 
ployed  along  with  other  tools.  Further,  such 
an  approach  is  incremental:  the  system  grows 
as  new  tools  are  created  and  added  to  the 
system.  The  tools  available  in  such  a  facility 
would  include  code  generators  for  a  variety  of 
machines,  test  data  generators,  regression 
analysis  programs,  on-line  documentation 
aids,  verification  programs,  etc. 

The.  feasibility  of  such  an  approach  has 
been  greatly  enhanced  by  our  development  of 
a  language -independent  programming  envi¬ 
ronment.  This  work  was  conceived  and  im¬ 
plemented  very  recently.  As  such,  the  impli¬ 
cations  and  significance  of  it  are  not  yet  clear, 
but  the  possibilities  are  very  exciting.  An 
interface  has  been  built  between  two  pro¬ 
gramming  systems:  BBN  LISP  and  EL/1  (pro¬ 
duced  at  Harvard).  This  interface  allows  the. 
user  to  program  in  me  EL/1  language,  but 
with  most  of  the  facilities  of  BBN  LISP  as  his 
programming  environment.  This  environment 
has  been  extensively  human -engineered  and 
it  undoubtedly  is  the  liest  on-line  program¬ 
ming  environment  yet  created.  These  facilities 
include  automatic  spel.ing  correction;  a  pow¬ 
erful  program -structure  editor;  break,  trace, 
and  advise  (modifications  of  the  interface  be¬ 
tween  one  routine  and  another)  capabilities; 
the  ability  to  modify  and/or  reissue  previous 
commands;  and  the  ability  to  undo  the  effects 
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of  previous  commands,  thus  recovering  earlier 
states. 

Thus,  the  EL/1  user  has  a  greatly  expanded 
facility  for  creating,  editing,  and  debugging 
programs.  That  programming  language  has 
been  transformed  into  a  programming  system. 
The  importance  of  such  a  transformation  can¬ 
not  be  overstated  in  terms  of  programmer 
productivity.  The  significance  of  this  work 
lies,  however,  not  in  the  interfacing  between 
LISP  and  EL/1,  but  rather  in  the  observation 
that  very  little  of  the  interface  or  the  capabil¬ 
ities  available  in  the  BBN’  LISP  programming 
environment  are  language  dependent.  Thus, 
once  the  system  is  operational  and  documen¬ 
tation  has  been  produced,  any  language  (with 
the  three  attributes  described  below)  can  be 
easily  accomodated  (a  few  man -days  of  effort 
is  estimated).  Furthermore,  since  all  commu¬ 
nication  between  the  LISP  environment  and 
the  programming  language  is  via  the  ARP  \ 
Network,  the  language  can  run  on  any  ma¬ 
chine  attached  to  the  Network. 

Three  properties  required  of  a  programming 
language  for  use  in  this  system  are:  1)  it  is 
available  over  the  ARPA  Network;  2)  it  has 
an  on-line  evaluator  (either  an  interpreter  or 
fast  compiler)  and  can  field  breaks  or  errors 
w'thin  a  computation;  and  !))  either  in  such 
breaks  or  at  the  top  level,  it  can  evaluate 
arbitrary  forms  in  that  language. 

The  system  is  currently  demonstratahle,  but 
many  of  the  facilities  are  either  unimplr- 
mented  or  undebugged.  However,  no  problems 
are  foreseen  in  completing  the  system.  It 
should  be  operational  and  well  documented 
by  the  beginning  of  June  1971  Figure  2.2  is  an 
example  of  EL/1  usage. 


From  the  standpoint  of  automatic  program¬ 
ming,  the  significance  of  this  work  lies  in  its 
demonstration  that  the  facilities  required  to 
produce  software  are  largely  language  inde¬ 
pendent.  This  validates  the  feasibility  of  AR- 
PA's  approach  of  creating  a  system  for  soft¬ 
ware  production  with  a  common  set  of  tools 
available  for  a  wide  variety  of  languages  and 
capable  of  producing  code  for  a  wide  variety 
of  machines. 

PROBLEM  A  CQUISITIOIS 

In  support  of  the  views  expressed  in  the 
Automatic  Programming  report  1 7 ].  the  major 
research  effort  here  has  lx;en  in  the  area  of 
problem  ocquis/tion  which  is  concerned  with 
obtaining  an  understanding  of  the  user's 
problem  and  the  domain  in  which  it  exists. 
This  is  necessary  so  that  the  following  process 
Ironsformul/on  phase  can  attempt  to  find  a 
sequence;  of  transformations  or  operations  in 
that  domain  which  will  obtain  the  solution 
required  by  the  user.  Thus,  the  problem  ac¬ 
quisition  phase  is  concerned  with  building  the 
complete  model  of  the  user's  domain;  the 
model  represents  the  interactions  between  the 
entities  of  that  domain,  and  the  effect  on  those 
entities  by  the  allowed  transformations  or 
operations  applicable  within  the  domain.  It  is 
our  primary  contention  that  only  through  the 
development  of  such  a  complete  model  of  the 
user’s  domain  car.  the  automatic  program 
ming  system  have;  any  degree  of  generality  in 
the  domains  for  which  it  is  applicable. 

Currently,  all  such  models  of  user  domains 
have  been  coded  into  a  system.  We  are  pro 
posing  that  suen  models  can  be  specified  to 
the  system  by  its  users,  and  that  through 
these  models  the  system  can  acquire  the 
knowledge  necessary  to  solve  problems 
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Figure  3.2  An  example  of  EL/1  usage.  The  EL/1 
prompt  character  is  either  -*■  or  a  number  followed 
by  a  :  followed  by  a  >  sign.  Thus,  user  input 
will  follow  one  of  these  symbols.  The  underscore 
represents  a  left  assignment  arrow. 
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within  these*  domains  and  the  understanding 
of  what  is  required  for  such  a  solution.  The 
two  main  issues,  then,  are  what  constitutes  an 
adequate  and  appropriate  model,  and  how 
such  a  model  is  specified  or  communicated  to 
the  system. 

Adequate  and  Appropriate  Model 

A  model  is  adequate  if  it  contains  a  com¬ 
plete  enough  description  of  the  relations  be¬ 
tween  the  entities  in  the  problem  domain  so 
that  a  sequence  of  operations  or  transforma¬ 
tions  on  this  model  can  be  built  to  solve  the 
problem  posed  by  the  user.  This  is  what  was 
referred  to  as  the  complete  model  earlier.  (See 
Problem -oriented  Model  above.)  Thus,  the  ad¬ 
equacy  of  a  model  is  dependent  upon  the  use 
of  that  model  to  solve  the  problem.  Operatio¬ 
nally,  this  requires  that  the  automatic^pro- 
gramming  system  is  capable  of  finding  the 
complete  set  of  applicable  transformations  on 
the  model  and  calculating  the  consequences  of 
each  of  these  actions.  The  appropriateness  of 
the  model  is  a  measure  of  how  well  suited  the 
available  transformations  are  to  solving  the 
problem  at  hand,  i.c„  an  adequate  model  can 
he  made  more  appropriate  by  adding  to  it 
nonprimitive  transformations,  made  up  of  a 
sequence  of  primitive  ones,  which  are  suitable 
building  blocks  for  the  problem  being  posed. 
The  model  may  also  be  made  more  appropri¬ 
ate  by  including  recommendations  about  the 
suitability  of  alternative  strategies  lor  se¬ 
quences  of  model  transformations. 

It  is  expected  that  the  well-known  problem 
of  building  a  powerful  general-purpose  prob¬ 
lem  solver  will  be  significantly  aided  hv  the 
user's  tailoring  of  the  specified  model  to  make 
it  more  appropriate  for  the  problem  at  hand. 


('onnnunieation  of  the  Model 

The  state  of  the  art  in  natural  language 
understanding  is  adequate  for  the  description 
of  problems  and  of  models  an  4  is  tieyond  our 
ability  to  utilize  the  information  thus  ob¬ 
tained,  and  hence,  should  not  be  a  bottleneck 
in  an  automatic  programming  system  Evi¬ 
dence  for  this  viewpoint  comes  from  the  work 
of  Woods  in  the  Moonrocks  Program,  from 
Winograd  in  the  Blocks  Description  Program, 
and  from  Martin  Kay  in  the  Mind  System. 
Each  of  these  systems  represents  an  alterna¬ 
tive  linguistic  technology  and  each  is  capable 
of  handling  a  wide  range  of  linguistic  forms 
within  the  domain  of  its  competence. 

The  basic  viewpoint  then  is  to  process  the 
user's  natural  language  communication  with 
the  understanding  that  it  is  meant  to  convey 
to  the  automatic  programming  system  a 
model  of  his  problem  domain.  Towards  this 
end.  the  system  can  extract  entities  and  the 
relationships  between  them  from  the  commu¬ 
nication.  It  can  further  query  the  user  as  to 
the  relationships  between  entities  which  have 
not,  as  yet.  been  explicitly  specified,  hut 
which  have  been  inferred  by  the  previous 
communication.  Such  inferences  by  the  sys¬ 
tem  about  the  incompleteness  of  the  model 
require  a  sophisticated  understanding  not 
only  of  the  communication,  but  of  the  types  of 
models  used  for  problem -domain  specifica¬ 
tion.  Unfortunately,  sophistication  in  both 
these;  areas  is  quite  limited.  The  need  in  com 
1 11 1  mica  I  ion  is  to  be  able  to  understand  how 
information  is  ordered  for  presentation,  bow 
context  is  established  and  utilized,  how  tin; 
capabilities  of  the  recipient  effect  the  connnu 
ideation,  and  how  these  capanilities  are  per¬ 
ceived  by  the  speaker.  The  need  in  modeling 
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is  to  have  a  space  of  possible  models,  an 
understanding  of  how  the  parts  of  a  model 
interact,  a  means  for  recognizing  incomplete¬ 
ness  in  models,  as  well  as  inconsistencies,  a 
means  for  obtaining  all  the  allowed  opera¬ 
tions  on  the  model,  and  the  means  for  trans¬ 
forming  the  models  with  these  operations. 

Human  l  se  of  W  orld  Knowledge 

An  experiment  w’as  devised  to  support  our 
contention  that  only  very  limited  use  of 
w'orld  knowledge  was  necessary  for  problem 
acquisition  in  a  new  domain.  Such  an  experi¬ 
ment  requires  the  ability  to  cut  off,  or  limit, 
the  interactions  between  the  new'  area  being 
explained  to  the  system  and  the  body  of 
world  knowledge  that  might  h :  brought  to 
bear  on  understanding  such  a  new  environ¬ 
ment.  This  c  uild  he  most  effectively  done  by 
translating  each  of  the  content  words  of  the 
new  domain  into  a  nonsense  word,  and  pre¬ 
senting  the  information  ns  a  mixture  of  nor¬ 
mal  English  with  the  translated  nonsense 
words  appearing  wherever  one  of  the  content 
words  of  the  domain  would  have  been  used. 

A  number  of  such  experiments  were  run. 
interactive  and  noninteractive,  with  both  sim¬ 
ple  and  complex  problem  domains,  and  the 
following  conclusions  were  reached: 

1)  subjects  are  able  to  acquire  knowledge 
about  a  domain  described  in  unfamiliar 
terms: 

2)  the  use  of  function  words  in  such  de¬ 
scriptions  is  very  important  to  the  under¬ 
standing  process: 

:t)  some  portion  of  such  acquisition  seems  to 
be  mechanizable  through  a  set  of  rules; 


4)  subjects  utilize  world  knowledge  exten¬ 
sively  to  test  local  plausibility  of  interpre¬ 
tations; 

5)  style  is  an  important  aspect  of  a  descrip¬ 
tion  which  enables  subjects  to  determine 
what  are  the  important  sections  arid  how  a 
cescription  flows  from  one  sentence  to  the 
next. 

In  addition,  the  protocols  of  these  experiments 
have  been  analyzed  and  a  set  of  rules  ob¬ 
tained  which,  it  is  felt,  will  begin  to  define  the 
way  such  models  are  built  and  knowledge  is 
extracted  from  such  passages. 

Finally,  a  representation  of  knowledge  is 
being  prepared  which  would  allow  utilization 
of  acquired  knowledge  in  multiple  ways,  such 
as  finding  all  elements  which  satisfy  a  certain 
relation,  testing  whether  a  particular  element 
satisfies  that  relation,  and  deducing  properties 
that  elements  which  satisfy  the  relation  must 
have.  Such  multiple  use  of  information  is 
critical  in  making  maximal  use  of  new  items 
of  information  to  gain  an  understanding  of  an 
environment.  The  proposed  representation  is 
halfway  between  procedural  and  table-driven 
representations  of  knowledge,  such  as  resolu¬ 
tion  theorem -pri  vers:  it  maintains,  it  is  felt, 
the  flexibility  of  the  procedural  representation 
while  allowing  the  use  of  that  information  to 
make  inferences  on  the  relationships  them¬ 
selves.  as  in  declarative  table -driven  type 
systems 

Efforts  in  this  area  are  very  formulative 
and  it  will  be  some  time  before  practical  re¬ 
sults  of  this  approach  are  available.  The 
eventual  impact,  however,  warrants  such  long 
term  involvement. 
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INTRODUCTION 

This  project,  begun  in  September  1972,  is 
developing  methodologies,  techniques,  and 
standards  for  the  analysis,  testing,  and  evalu¬ 
ation  of  the  software  security  features  of  op¬ 
erating  systems.  The  project  is  providing  a 
variety  of  means  for  answering  the  question, 
"Given  an  operating  system,  what  tests  and 
procedures  can  and  should  be  applied  in  order 
to  determine  whether  the  operating  system 
can  withstand  accidental  or  malicious  at¬ 
tempts  to  access  or  destroy  protected  infor¬ 
mation.  arid  how  should  it  lx:  designed  so 
as  to  withstand  such  occurrences?".  In  other 
words,  the  research  is  aimed  at  directly  sup¬ 
porting  the  software  security  requirements 
issued  by  1)01)  security  policy-making  agen¬ 
cies. 

Project  Approaches 

Three  separate  but  complimentary  ap¬ 
proaches  are  being  pursued:  Empirical  System 
Study.  Protection  The  ary,  and  Program  Verifica¬ 
tion. 

Empirical  System  Study. 

Kmpirical  system  study  focuses  on  near- 
term  solutions  to  the  requirement  to  operate 
computers,  with  classified  and  unclassified 
information  simultaneously,  in  resource -shar¬ 
ing  mode.  Currently.  1)01)  has  over  :t.4()() 
computers  in  its  inventory,  with  an  additional 
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1.600  computers  in  use  at  its  contractors’  fa¬ 
cilities.  none  of  which  can  be  operated  in 
resource -sharing  mode  because  none  have  an 
operating  system  which  can  withstand  mali¬ 
cious  attack.  While  there  is  considerable  re¬ 
search  in  the  production  of  secure  operating 
systems,  the  results  of  this  research  will  only 
lie  felt  in  the  long  term  since  even  if  secure 
systems  were  currently  available,  it  would 
lake  at  least  five  years  for  the  government 
and  its  contractors  to  replace  the  current 
computer  inventory  ami  convert  to  the  new 
systems.  Faced  with  the  requirement  of  oper¬ 
ating  in  resource -sharing  mode  and  the  lack 
of  operating  systems  to  support  such  a  re¬ 
quirement.  this  research  is  aimed  at  finding 
interim  solutions  by  identifying: 

1)  vulnerabilities  of  contemporary  systems 
and  how  these  vulnerabilities  transcend 
manufactures  and  architectures: 

2)  security  trade  offs  which  would  allow 
contemporary  systems  to  operate  under  re¬ 
stricted  forms  of  resource -sharing;  and 

2)  policies  and  procedures  for  testing  and 
approving  systems  for  such  operation. 

The  work  to  date  has  resulted  in  the  devel¬ 
opment  of  a  new  operational  protocol  for  test 
ing  and  evaluating  operating  s\  stems,  the  (.at  - 
egori/.alion  ol  known  security  Haws  in  con 
temporary  systems  into  generic  classes  which 
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can  be  used  It)  predict  errors  in  future  sys¬ 
tems,  and  the  successful  use  of  the  above 
protocol  and  categorization  in  discovering  se¬ 
curity  flaws  in  the  Mu  I  tics  operating  system. 

1‘rotrrtion  Theory. 

With  respect  to  protection  in  operating  sys¬ 
tems,  there  exists  much  practice  but  little 
supporting  theory.  This  subproject  seeks  to 
help  remedy  this  situation  by  developing: 

1)  a  hasis  for  more  formally  describing  pro¬ 
tection-forms  and  protection -mechanisms,' 

2)  a  methodology  for  abstracting  the  pro¬ 
tection-forms  of  given  protection  schemes: 
and 

3)  a  framework  for  the  comparison  and 
evaluation  of  protection  schemes  them¬ 
selves. 

The  inductive  and  deductive  approaches  em¬ 
ployed  have  resulted  in  the  lieginnings  of  a 
taxonomic  framework.  Byproducts  of  this 
subproject  are  an  annotated  protection  bibli¬ 
ography  and  a  glossary  of  protection -scheme 
terminology  and  jargon. 

I’rofirtini  I  vrijieatiou. 

Verifying  a  computer  program  means  dem¬ 
onstrating  that  the  program  is  consistent  with 
documentation  or  statements  of  what  the  pro¬ 
gram  is  to  do.  Current  work  is  concentrating 
on  providing  computer  assistance  for  verify¬ 
ing  programs.  One  operational  aid  resulting 
from  I  hi1  group's  work,  called  a  verification 
condition  generator,  takes  as  input  a  program  to 
lx*  verified  and  also  documentation  of  what 
that  program  is  to  do.  The  output  from  the 
verilication  condition  generator  is  a  set  of 
mathematical  lemmas,  called  verification  eon 
ilili ons.  Proving  these  lemmas  demonstrates 


that  the  program  is  consistent  with  its  docu¬ 
mentation,  and  hence  the  program  is  verified. 

Numerous  nontrivial  priigrams  have  been 
verified  hy  proving  by  hand  the  lemmas.  Sev¬ 
eral  of  these  programs  have  also  been  verified 
by  using  an  interactive  theorem  prover.  The 
success  of  the  verification  condition  generator 
has  suggested  additional  components  to  in¬ 
crease  computer  assistance  in  verifying  pro¬ 
grams. 

The  empirical  system  s'.udy.  ties  ides  obtain¬ 
ing  certain  results  that  apply  to  current  Der¬ 
ating  systems,  provides  useful  input  to  the 
other  two  areas.  Both  strengths  and  weak¬ 
nesses  of  current  operating  systems  must  Ik? 
accounted  for  in  protection  theory  and  in 
program  verification.  Protection  theory  pro¬ 
vides  some  of  the  statements  to  he  verified 
alxmt  secure  systems.  In  turn,  the  empirical 
study  is  influenced  by  the  other  two  areas. 

Even  though  such  matters  as  physical  se¬ 
curity,  personnel  security,  communication  se¬ 
curity.  user  identification,  hardware  correct¬ 
ness,  and  hardware  reliability  are  important 
and  challenging  parts  of  the  overall  security 
problem,  they  have  lieen  excluded  from  this 
work  in  order  to  concentrate  on  the  software 
aspects  of  the  overall  problem, 

EMPIRICAL  SYSTEM  STUDY 

This  subproject  is  characterizing  contempo¬ 
rary  operating  systems  in  a  security  sense, 
idcntifyi,'g  their  strengths  and  vulnerabilities, 
and  developing  an  empirical  methodology  for 
discovering  security  flaws  in  future  systems. 
The  work  to  dale  has  resulted  in  the  develop¬ 
ment  ol  a  new  operational  protocol  for  testing 
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and  evaluating  operating  systems,  the  catego¬ 
rization  of  known  security  flaws  in  contem¬ 
porary  systems  into  generic  classes  r  hich  can 
be  used  to  predict  errors  in  future  systems, 
and  the  successful  use  of  the  above  protocol 
and  categorization  in  discovering  security 
flaws  in  the  Multics  operating  system. 

Opera  I  in*!  System  Characterization 

(thl  Pntlocol. 

All  previous  security  test  and  evaluation 
(ST&E)  activities  known  to  this  group  have 
been  carried  out  under  war  game-like  condi¬ 
tions,  with  an  aggressor  trying  to  penetrate 
the  system,  and  a  defender  attempting  to  de¬ 
tect  such  attempts.  In  general,  the  determina¬ 
tion  that  a  given  system  was  either  insecure 
or  seen  re  rested  entirely  with  the  success  or 
failure  of  the  penetration  attempt 

U  ur  fninn-  test.  An  example  of  the  extreme 
to  which  ST&E  protocol  has  l)een  carried  is 
best  exemplified  in  a  recent  test  in  which,  in 
addition  to  finding  a  security  flaw,  the  test 
was  subject  to  the  following  conditions: 

1)  the  security  flaw  had  to  be  used  in  an 
undetected  manner  to  repeatedly  access  a 
pseudo  -classi find  fi  le; 

2)  no  information  concerning  the  name  and 
content  -’  o'"  the  pseudo  -classified  file  was 
given  to  'he  ST&E  people: 

A)  no  information  concerning  the  ,  •  o 
structure  of  the  system  being  teste.u 
given  to  the  ST&E  people  prior  to  the  test: 

4)  the  entire  test  was  to  he  conducted 
within  a  two  week  period. 

t  he  user,  on  the  other  hand,  could  know  the 
names  of  the  ST&E  people  and  could  actively 
defend  the  system  by  isolating  and  selectively 


scrutinizing  the  ST&E  inputs,  by  unrealisti¬ 
cally  disguising  the  pseudo -classified  file,  and 
by  making  unannounced  changes  to  the  sys¬ 
tem  during  the  test.  It  is  unimportant  hether 
these  were,  in  fact,  done;  that  those  actions 
were  not  precluded  is  important. 

While  the  ST&E  people  did  meet  all  of  the 
above  conditions  and  thus  showed  the  system 
to  be  insecure  using  the;  above  definition,  the 
activity  was  clearly  not  an  analysis  of  the 
security  of  the  system,  but  a  test  of  the  inge¬ 
nuity  of  the  ST&E  people  in  implementing 
programs  to  manipulate  the  computer  hard¬ 
ware  and  operating  system  after  control  had 
been  usurped  from  the  system.  This  was 
dramatized  by  the  fact  that  over  75%  of  the 
ST&E  activity  was  devoted  to  implementing 
programs  to  determine  the  security  perimeter, 
to  testing  the  security  flaw,  and  to  exploiting 
the  flaw  in  finding  and  accessing  protected 
information.  Less  than  25%  of  the  ST&E  ac¬ 
tivity  was  devoted  to  actually  analyzing  the 
security  features  of  the  system. 

Problems.  Major  problems  associated  with 
the  old  ST&E  protocol  are  the  lack  of  stability 
of  the  system  being  tested  as  a  result  of  sys¬ 
tem  modifications  made  during  the  test,  the 
use  of  penetration  programs  to  verify  the 
existence  of  security  Haws,  the  limited  range 
of  possible  lest  results  of  the  ST&E  activity, 
and  the  testing  of  systems  under  their  best 
case  conditions. 

\eir  Priitmiil. 

The  new  ST&E  protocol  eliminates  these 
problems. 

N table  system.  The  first  Feature  ol  the  new 
protocol  is  that  the  lest  is  carried  out  on  a 
system  whose  development  is  frozen  for  the 


35 


COMPUTER  SOFTWARE  ASSURANCE 


duration  of  the  test.  As  such,  both  the  manu¬ 
facturer  and  the  install  tion  are  prohibited 
from  making  modificatOns  to  the  system  dur¬ 
ing  the  test.  This  does  not  preclude  the  im¬ 
provement  of  the  security  features  of  the  sys¬ 
tem  during  the  ST&E  activity,  but  it  does 
preclude  the  incorporation  of  those  improve¬ 
ments  into  the  system  be  ig  tested  once  the 
test  activity  has  commenced.  The  importance 
of  this  test  requirement  is  to  prevent  a  reoc¬ 
currence  of  the  following. 

In  a  recent  test,  an  installation,  upon  scruti¬ 
nizing  the  ST&E  input,  saw  that  their  system 
was  about  to  be  penetrated  and  proceeded  to 
lock  the  ST&E  people  out  of  the  system  for  a 
three  week  period  whde  system  modifications 
were  made  to  fix  the  security  flaw.  At  the 
conclusion  of  the  test,  the  installation  domed 
the  e  dstence  of  the  original  security  flaw. 

\<i  programming.  The  second  feature  is  the 
elimination  of  the  writing  of  programs  to 
verify  security  flaws.  Instead,  the  verification 
is  by  joint  agreement  of  the  manufacturer 
(and/or  installation)  and  the  ST&E  people. 
Only  in  the  unlikely  event  of  disagreemeni 
are  programs  written  to  verify  the  flaw.  This 
eliminates  situations  such  as  the  one  cited 
above  in  which  ST&E  people  devoted  more 
time  to  exploiting  a  single  security  Haw  than 
to  analyzing  the  system  for  other  flaws. 

Kxpnnilril  irsi  rrsuh the  third  feature 
involves  the  expansion  of  the  range;  of  possi¬ 
ble  outcomes  of  ST&E  activity.  The  security 
determination  of  a  system  is  far  from  settled 
by  a  penetration  attempt.  At  least  t he  follow 
irig  can  result  from  a  summary  of  ST&K  ac¬ 
tivity: 


1)  the  system  was  proven  to  be  secure: 

2)  the  system  is  believed  to  be  secure; 

Tj  the  system  is  believed  to  be  insecure; 

4)  the  system  was  proven  to  be  insecure; 

5)  no  comment  can  be  mode  about  the  se¬ 
curity  of  the  system. 

An  expanded  scale  such  as  the  above,  in  ad¬ 
dition  to  more  adequately  summarizing  the 
ST&E  activity,  eliminates  the  anomalous  situ¬ 
ation  in  which  penetration  is  equated  with 
total  insecurity  while  nonpenetration  is 
equated  with  total  security. 

It  «r. si  «•«*«•.  A  final  feature  is  the  evalua¬ 
tion  of  systems  under  worst  case  conditions. 
The  goal  of  the  ST&E  activity  is  to  provide 
1)01)  Security  Policy  with  a  full  and  impar¬ 
tial  analysis  of  the  system  under  test,  and  this 
can  only  be  achieved  with  worst  case  testing. 
It  cannot  be  achieved  where  war  game  condi¬ 
tions  are  imposed  on  the  test,  where  the  test 
must  be  carried  out  in  a  limited  time,  where 
all  information  concerning  the  system  is 
withheld,  or  where  extraneous  activities  such 
as  finding  a  pseudo -classified  file  are  required. 
A  comprehensive  analysis  can  only  he  carried 
out  when  the  ST&E  people  have  complete 
access  to  the  system  and  all  information 
about  the  system,  and  the  ability  to  test  under 
actual  operations. 

Security  Flaws  llantlhook 

Work  has  begun  in  generating  an  ST&E 
handbook.  The  handbook  is  intended  for  use 
by  1)01)  personnel  in  evaluating  operating 
systems.  Th<>  handbook  is  written  in  two  sec¬ 
tions.  The  first  section  details  the  organ iza 
tionat  aspects  of  security  threats  by  present 
ing  a  methodology  tor  establishing  and  oper¬ 
ating  a  penetration  effort. 
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The  second  section  details  specific  security 
flaws  found  in  various  contemporary  operat¬ 
ing  systems  and  discusses  their  generalization 
to  other  operating  systems.  This  section  is  of 
particular  importance  to  persons  responsible 
for  designing  or  evaluating  systems  since  it 
not  only  provides  an  annotated  list  of  security 
flaws,  but  also  a  framework  for  predicting 
where  future  flaws  will  most  likely  occur. 
Portions  of  this  handbook  have  been  pre¬ 
sented  at  Department  of  Defense  Computer 
Institute  courses  on  computer  security.  (See 
ACTIVITIES  below.' 


Using  the  newly  formulated  ST&E  prot<x;ol 
and  the  handbook,  a  test  was  conducted  of  the 
Multics  operating  system.  The  Multics  system 
was  chosen  for  the  test  because  it  represented 
the  most  advanced  general-purpose  operating 
system  in  which  information  protection  was  a 
fundamental  objective  of  the  design.  The  test 
resulted  in  the  discovery  of  security  flaws  in 
the  Multics  system  and  demonstrated  the 
practicability  of  both  the  protocol  and  the 
handbook. 

Several  interesting  and  beneficial  results 
were  noted.  First,  no  machine  time  was  used 
in  the  ST&E  activity.  All  proposed  security 
flaws  were  either  verified  or  discarded  with  a 
single  telephone  call.  As  a  result,  there  were 
no  machine  costs  and  no  disruption  of  com¬ 
puter  service  to  the  Multics  use".  Second, 
other  than  the  ST&E  handbook,  the  most  ef¬ 
fective  tool  in  discovering  security  flaws  con¬ 
tinues  to  be  an  information  retrieval  system 
for  storing,  retrieving,  and  operating  on 
source-level  documentation. 


Research  Trent! s 

Research  in  empirical  system  study  for  the 
coming  year  will  include: 

1)  The  continued  development  of  the  ST&E 
handbook  with  the  inclusion  of  results  from 
other  computer  security  studies,  such  as  the 
Air  Force  Computer  Security  Technology 
Planning  Study  (4). 

2)  The  continued  dissemination  of  this  pro¬ 
ject's  successful  methodology  for  discover¬ 
ing  security  flaws.  This  includes  participa¬ 
tion  in  Department  of  Defense  Computer 
institute  and  other  governmental  seminars 
in  computer  security,  as  well  as  nongovern¬ 
mental  lectures,  seminars,  and  symposia. 

3)  The  integration  of  this  project's  .security- 
flaw  discovery  methodology  with  the 
ARPA -sponsored  MIT  effort  to  develop  a 
cert ifiably  secure  version  of  the  Multics 
operating  system 

4)  The  incorporation  of  the  above  test  pro¬ 
tocol  i n to  the  ADP  Security  Manual  |f>]. 

PROTECTION  THEORY 

I’rotcition:  Control  of  Operations. 

Protection  in  an  operating  system  is  con¬ 
cerned  with  the  prevention  of  certain  opera¬ 
tions  under  certain  conditions,  where  an  oper¬ 
ation  is  the  application  of  an  operator  by  a 
subject  (active  entity)  to  one  or  more  ob/eels 
(passive  entities).  Operators  may  range  from 
primitive  read  and  write  accesses,  through 
basic  processor  instructions,  to  software  pro¬ 
cedures  of  any  size  or  degree  of  complexity. 
Subjects  are  users  and  the  internal  processes 
for  which  they  are  directly  or  ind  ectlv  re¬ 
sponsible.  as  well  as  the  processes  of  the  oper¬ 
ating  system  itself.  Objects  may  be  anything 
which  can  Ik;  denoted  as  operands,  including 
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cells  of  virtual  or  physical  storage  and  too 
values  represented  in  them,  com|X)site  infor¬ 
mation  structures  (including  procedures),  var¬ 
ious  other  types  of  resources,  and  processes 
themselves. 

I'rolrt  lion  Schemes. 

As  parts  of  operating  systems,  protection 
schemes  exist  in  various  conceptual,  design, 
implementation,  and  operational  versions.  A 
particular  progression  of  versions,  from  con¬ 
ceptual  image  to  operational  system,  charac¬ 
terized  by  increasing  degrees  of  completeness, 
concreteness,  and  formality,  is  called  a  version 
geiwo/ogy. 

In  addition,  tin;  protection  schism;  speediod 
by  any  version  has  both  an  external  and  an 
internal  aspect,  a  distinction  fundamental  to 
the  science  of  design  |i»).  The  external  aspect 
of  a  protection  scheme,  which  exhibits  ds 
functionality  from  the  point  of  view  ol  the 
operating  system's  user  environment,  is  called 
a  protection  form  or  p-form.  The  internal  as¬ 
pect,  which  consists  of  a  set  of  protect  ion - 
enforcing  procedures  and  data  I  rases,  is  refer¬ 
red  to  collectively  as  a  protection  meeliooism  or 
p  -mechanism. 

l*roblrm  Domain 

This  subproject  has  been  underway  lor  less 
than  six  months.  Its  original  motivation  came 
from  the  observation  that  for  protection  in 
operating  systems,  there  exists  much  practice 
lint  little  supporting  theory:  there  are  many 
schemes  existing  at  various  genealogical  lev¬ 
els.  lint  little  attempt  has  been  made  to  ab 
strait  assess,  or  compare  their  respective 
p  forms,  not  to  mention  verifying  p- mecha¬ 
nisms  with  relcrcnce  to  the  p  forms  they 
purport  to  fulldl.  The  goals  ol  this  subproject 


are  to  help  remedy  this  situation  by  develop¬ 
ing: 

1)  a  basis  lor  mure  formally  describing 
p-lorms  ami  p -mechanisms: 

2)  the  methodology  for  abstracting  the 
p- forms  of  given  prolix:! ion  schemes:  and 

:t)  a  framework  for  the  comparison  and 
evaluation  of  p -forms  themselves,  Ixilh 
those  associated  with  actual  p- mechanisms 
as  well  as  those  for  which  no  practical 
p -mechanisms  have  yet  been  promised. 

These  interrelated  goals  have  the  following 
utilities: 

1)  A  means  for  formally  describing  p-forms 
allows  them  lo  lx?  more  readily  classified 
with  respect  to  the  kinds  of  protection  they 
provide.  i.e..  it  leads  lo  a  taxonomy  of 
p-forms  and  thus  of  protection  schemes 
themselves.  A  formal  description  language 
will  also  be  of  value  in  the  future  applica¬ 
tion  of  formal  verification  techniques  to 
p  mechanism  design  and  implementatiiin 
versions.  (See  PROGRAM  VERIFICATION 
below.) 

2)  The  ability  to  classify,  compare,  and 
evaluate  p  forms  is  of  value,  both  lo  de¬ 
signers  who  wish  to  know  what  kind  of 
protection  lo  provide  in  their  systems,  as 
well  as  lo  users  who  wish  lo  know  what 
kind  ol  protection  various  systems  can  he 
expected  In  provide,  and  who  wish  In  judge 
their  appropriateness  lo  particular  social, 
commercial,  military,  etc.  environments.  A 
p  form  taxonomy  allows  (or  lories)  opera  I 
mg  system  designers  lo  declare  their  lie 
signs  with  res|x;ct  lo  protection  functional 
ily,  greatly  facilitating  these  omparisons 
evaluations,  and  judgments. 
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3)  Progress  in  the  development  of  a  de¬ 
scriptive  language  and  its  basic  terminology 
can  only  tend  to  enhance  communication 
among  designers  and  others  working  in  the 
area  of  protection,  and  unify  their  efforts. 

i'omplimentory  A  pprottcltcs 

Both  the  inductive  and  deductive  ap¬ 
proaches  are  being  employed  The  inductive 
approach  begins  by  surveying  the  existing 
population  of  protection  schemes,  as  reported 
in  the  literature  and  known  through  firsthand 
contacts,  and  by  studying  selected  representa¬ 
tive  schemes.  There  are  two  purposes: 

1)  to  identify  and  distinguish  generic  char¬ 
acteristics  versus  peculiar  ones,  in  order  to 
form  an  empirical  basis  for  description  and 
model  formation;  and 

2)  to  gain  experience  in  abstracting 
p -forms. 

The  deductive  approach  is  based  on  an 
analysis,  quite  independent  of  characteristics 
of  actual  p-mechariisms  but  within  the  theo¬ 
retical  context  of  operating  systems,  of  the 
fundamental  meanings  of  protection  and  con¬ 
sequent  notions.  This  analysis  is  expected  to 
result  in  a  general  o-form  model,  whose  pro¬ 
visions  encompass  at  least  those  of  all  fore¬ 
seeable’  practical  p  forms,  and  whose  param¬ 
eters  are  expressed  in  terms  of  their  functio¬ 
nality.  P- forms  can  then  tie  descrited  as  in¬ 
stances  generated  from  this  model  by  specify¬ 
ing  the  parameters,  which  among  other  bene¬ 
fits.  makes  comparisons  straightforward. 

Employing  the  two  approaches  concur¬ 
rently  provides  the  opportunity  for  mutual 
validation  of  results.  The  deductive  approach 
is  also  important  because  it  allows  the  identi¬ 
fication  of  classes  of  protection  schemes 


which  might  be  missed  if  only  existing 
schemes  were  considered. 

Reference  Tttols 

Protection  Hihliofiroftliy. 

The  initial  survey  of  protection  schemes 
involved  a  review  of  the  literature  and  the 
start  of  an  annotated  bibliography  which  is 
somewhat  different  from  existing  bibliogra¬ 
phies  [7- 1()|  in  that  it  focuses  primarily  on 
protection,  to  the  exclusion  of  other  aspects  of 
security  and  privacy.  The  survey  has  teen 
augmented  by  discussions  with  researchers 
from  MIT/Prujeot  MAO.  Carnegie  Mellon 
University,  and  the  University  of  California 
ai  Berkeley. 

Protection  (ilosstiry. 

Another  result  of  this  survey  is  a  glossary 
of  terminology  and  jargon  used  by  various 
workers  in  connection  with  various  protection 
schemes.  Each  entry  in  this  glossary  will  con¬ 
tain  references  Imth  to  instances  of  its  use  as 
well  as  to  other  entries  associated  with  the 
same  or  a  similar  concept.  Such  a  glossary  is 
fell  to  be  a  potentially  valuable  tool  in  recon¬ 
ciling  similar  and  diverse  efforts  in  the  area, 
ami  is  intended  for  publication. 

Elements  of  n  Protection  Motlcl 

P-mcclninistn  Elements. 

From  the  initial  survev  the  subproject  has 
begun  to  learn  how  to  identify,  in  any  given 
protection  scheme,  its  peculiar  representation 
of  those  elements  and  that  structure  which 
are  generic  to  all  p -mechanisms.  The  essence 
of  a  protection  scheme  is  a  set  of  ;«•/ mission 
functions,  the  evaluations  of  which  are  prel 
lidos  to  various  operations  at  hardware 
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firmware,  and  software  levels.  Like  an  ordi¬ 
nary  Boolean  function,  the  inputs  of  a  per¬ 
mission  function  are  observable  properties  of 
selected  entities:  (functions  of)  these  values 
are  tested  against  reference  values;  a  Boolean 
combination  is  applied  to  the  resulting  primi¬ 
tive  propositions;  and  the  output  is  its  truth 
value.  In  the  case  of  a  permission  function: 

1)  the  entities  whose  properties  are  ob¬ 
served  are  normally  one  or  more  of  the 
subjects,  operators,  and  objects  involved,  al¬ 
though  occasionally  other  values  of  the  op 
erating  system  state  (e.g.,  current  resource 
allocations)  may  be  utilized;  and 

2)  a  result  of  "false''  inhibits  the  operation 
in  question. 

The  set  of  properties  or  state  values  utilized 
by  permission  functions  are  collectively  called 
the  actual  stole  of  the  system.  The  collection  of 
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current  permission  functions  and  their  associ 
ated  reference  values  are  the  [mlicy  stole.  (See 
Figure  4.1.)  A  protecting  opemlor  is  one  to 
which  a  permission  function  is  attached,  and 
a  protected  obj.-cf  is  one  to  which  is  applied 
only  protecting  operators  which  recognize  the 
conditions  associated  with  it.  Both  the  actual 
state  and  the  policy  state  must  obviously  he 
protected.  It  is  ch  ar  that  at  least  a  part  of  the 
policy  state  must  lx;  variable,  to  reflect  intents 
expressed  by  users  with  respect  to  protection 
of  objects  for  which  they  are  responsible,  nr  to 
be  created  by  the  operating  system  on  the 
basis  of  default  policies  when  more  explicit 
intent  information  is  lacking  |7l|.  It  is  equally 
clear  that  part  of  the  policy  state  must  remain 
constant.  i.e„  protected  from  any  change, 
namely  that  part  which  protects  the  policy 
state  itself  at  the  highest  metapolicy  level.  A 
framework  for  the  comparative  analysis  of 
p- mechanisms  is  evolving  from  these  and 
other  observations. 

/‘-/arm  f./i  irii'H  Is. 

The  study  of  fundamental  implications  (de¬ 
ductive  approach)  has  been  fruitful  in  that 
the  basic  elements  of  p-fcun  description  have 
been  identified  1’he  f  mctioimiily,  or  behavior, 
of  a  | >  form  is  defined  in  the  following  way. 
Its  .scope  is  the  class  of  operations  (i.e„  subjects, 
operators,  and  objects)  it  covers.  Its  cond/lionoi- 
ity  is  the  class  of  conditions  which  may  1m? 
associated  with  these  operations,  expressed  in 
terms  of  actual  state  properties  and  policy 
state  values  and  conditionals.  A  p  form  can 
then  be  regarded  as  a  mapping  from  a  class  of 
user -expressed  intents  inio  some  set  of  per 
mission  functions  (with  certain  other  permis 
sion  functions  fixed,  as  stated  above),  when: 
intents  as  well  as  permission  functions  are 


40 


limited  by  the  p-form  scope  and  conditional¬ 
ity.  Some  of  the  obvious  limitations  on  a  prac¬ 
tical  p-form  are  that  it  must  be  implemen- 
tahle  into  a  reasonably  efficient  p-mechanism, 
the  scope  can  include  only  entities  denoiable 
by  the  user  and  identifiable  by  the  operating 
system,  and  identifications  must  be  nonforge  - 
able.  Any  practical  p-form  is  only  an  approx¬ 
imation  to  an  ideal  p-form  in  which  any  user 
intent  whatsoever  which  can  be  stated  infor¬ 
mally  can  also  he  expressed  formally  and 
honored. 

As  a  simple  example  of  the  usefulness  of 
scope  and  conditionality  as  criteria,  an  impor¬ 
tant  subclass  of  p- forms  is  singled  out. 
namely  those  in  which: 

1)  the  scope  includes  only  a  few  primitive 
operators  such  as  "read",  "write",  and  "ex¬ 
ecute":  and 

2)  protection  conditions  are  regarded  us  rel¬ 
atively  static. 

This  class  is  important  because  it  has  received 
the  most  attention  and  has  been  regarded  as 
most  widely  applicable.  In  associated 
p-mechanisms.  the  results  of  initial  permis¬ 
sion  function  evaluations  can  generally  be 
stored  as  rights  or  capabilities  which  are  re¬ 
garded  as  "possessed  '  by  subjects,  so  that 
permission  subsequently  depends  only  on  the. 
test  of  a  bit  corresponding  to  the  selected 
operator.  This  has  led  to  p-mechanisms  in 
which  the  protection  and  policy  states  are 
represented  by  sets  of  rights  called  environ¬ 
ments  or  domains  in  which  subjects  operate 
and  through  which  they  move  (72-1-J|.  For 
more  dynamic  conditions,  of  course,  such 
schemes  are  less  appropriate,  since  when  con¬ 
ditions  change  it  may  be  difficult  to  revoke 
the  dependent  rights. 
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Research  Trends 

During  the  coming  year  the  pursuit  of  the 
study  of  fundamental  p-form  elements  and 
their  relations  will  continue  along  with  the 
analysis  of  p-mechanisms  through  a  more 
intensive  and  thorough  review  of  existing 
schemes  and  ideas.  These  two  approaches  are 
expected  to  produce  a  common  description 
framework  into  which  various  p-forms  and 
p-mechanisms  can  be  conveniently  placed. 

In  addition  to  the  continued  development  of 
the  protection  theory  glossary,  it  is  planned  to 
glean  from  the  above -mentioned  review  a  set 
of  liench  mark  problems  with  which  users 
and  designers  have  been  specifically  con¬ 
cerned,  to  serve  as  one  test  of  the  generality  of 
any  p-form  model  which  evolves.  This  is  a 
large  set:  an  attempt  will  lx:  made  to  reduce  it 
to  a  set  of  generic  types  hy  stating  the  prob¬ 
lems  in  terms  of  the  permission  functions 
required  for  their  solution. 

The  study  of  fundamental  elements  and 
relations  has  only  begun,  and  several  prob¬ 
lems  lie  immediately  ahead.  The  first  is  un¬ 
derstanding  how  conditions  of  the  policy  state 
are  attached  to  operators,  subjects,  and  objects 
of  protection.  A  related  topic  is  that  of  protec¬ 
tion  classes:  classes  of  subjects,  operators,  or 
objects  whose  protection  conditions  are  the 
same.  These  play  a  prominent  role  in  most 
existing  schemes. 

An  important  problem  is  the  necessity  of 
distinguishing  among  the  various  levels  01 
representation  which  manifest  hemselves  in 
operating  systems.  Scope  entities  are  in  many 
cases  defined  hierarchically.  For  example,  a 
user  is  represented  by  the  major  processes  he 
commands,  these  by  sets  of  cooperating  sub¬ 
processes  o'-  tasks,  these  in  turn  by  serpienc.es 
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of  more  elemcMitmy  processes  (of  which  the 
execution  of  a  basic  machine  instruction  is  a 
primitive- -hut  only  with  respect  to  the 
processor's  external  aspect).  Operators  exist  in 
a  similar  representational  hierarchy,  as  do 
elements  of  an  information -data -storage 
structure.  A  p-form  concerned  with  protec¬ 
tion  at  a  particular  representational  level  can¬ 
not  he  directly  compared  with  another  which 
protects  objects  at  a  different  level. 

PROG  RA  M  J  ERIFICA  TIO\ 

I  crificotion-- Definition.  Problems.  a>  •/ 
Relevance  la  Protection 

To  verify  a  computer  program  means  to 
demonstrate  that  the  program  is  consistent 
with  documentation  or  statements  of  what 
the  program  is  to  do.  This  demonstration  is  by 
rigorous,  often  formal,  mathematical  proof. 
Program  verification  is  an  important  par!  ol 
•uuflwaft?  uvamma*  because  Ihe  ultimate  aim 
is  to  be  able  to  prove  statements  about  protec¬ 
tion  forms  and  protection  mechanisms  that 
are  designed  and  implemented  in  operating 
systems.  (See  PROTECTION  THEORY  above.) 
The  proofs  of  statements  about  protection,  to 
be  provided  to  users  and  managers  of  com¬ 
puter  systems,  will  be  part  of  the  reasonable 
and  adequate  assurances  that  such  systems  do 
provide  Ihe  desired  level  of  protection.  The 
significance  to  1)011  becomes  immediately  ap¬ 
parent  by  substituting  Ihe  word  M.rurily  for 
protect  ion.  A  critical  need  is  to  permit  com 
puter  access  to  classified  documents  while 
maintaining  adequate  safeguards  against  se¬ 
curity  violations. 

Current  \e.  ibcation  techniques  )l.T-17|  are 
inadequate  for  proving  protection  statements 
about  (  in rent  operating  systems.  It  is  possible 
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to  prove  statements  about  hundreds  of  lines 
of  code,  but  not  about  thousands  of  lines. 
lx;cause  of  practical  considerations  of  the 
amount  of  detailed,  human  effort  involved. 
Moreover,  personal  experience  has  shown 
that  verification  is  often  made  more  difficult 
than  necessary  when  programs  are  written 
without  consideration  of  the  need  to  verify 
the  finished  program. 

These  difficulties  can  he  overcome  or 
avoided.  The  MIT/Project  MAC  Multics 
group,  among  others,  speaks  of  redesigning 
operating  systems  to  provide  a  security  kernel 
whereby  the  protection  mechanisms  are  re¬ 
stricted  to  a  hopefully  small  part  of  the  entire 
operating  system.  Only  the  kernel  would  need 
to  be  verified,  since  all  the  protection  is  ac¬ 
complished  through  the  kernel:  in  particular, 
errors  in  nonkernel  parts  cannot  affect  protec¬ 
tion  Whether  the  xm>  and  complexity  td'  the 
kerne!  will  permit  verification  is  not  yet 
known,  hut  in  any  event  Ihe  entire  system 
need  not  he  verified. 

The  amount  of  detailed  effort  currently  re¬ 
quired  can  be  eliminated  in  several  ways  (to 
be  explained  below).  The  desire  to  verify  pro¬ 
grams  is  already  having  an  effect  on  pro¬ 
gramming  language  design  |Pl-i’0|  with  re 
stricted  features,  syntax,  and  semantics  being 
justified  in  part  by  this  need.  Numerous  pro¬ 
gramming  disciplines,  such  as  chief  program 
mer  team  |..'J|  and  structured  programming 
(including  few  or  no  go-to  statements)  are 
being  advocated  as  ways  to  produce  heltei 
programs.  Obeying  these  disciplines  will  in 
crease  the  likelihood  that  the  resulting  pm 
grams  will  be  easier  to  verify. 


mmrnu mmmmm 


COMPUTER  SOFTWARE  ASSURANCE 


There  is  evidence  that  programs  involving 
parallel  control  structure  can  be  verified  1 2.1- 
28)  by  using  some  of  the  same  methods,  some¬ 
times  generalized,  that  are  successful  on  pro¬ 
grams  with  only  sequential  control  structure. 
The  need  to  verify  parallel  programs  arises,  of 
course,  since  the  protection  mechanisms  are 
part  of  operating  systems  which  involve  par¬ 
allelism.  Thus  there  is  good  reason  to  believe 
that  statements  on  protection  will  be  able  to 
be  verified  at  reasonable  cost, 

Existing  and  Planned  Computer 
Assistance  for  \  erification 

Current  subproject  work,  continuing  joint 
work  of  S.  lgarashi.  R.  London,  and  II  Luck- 
ham,  is  concentrating  on  providing  computer 
assistance  for  verifying  programs.  The  human 
effort  required  for  verification  is  intended  to 
be  significantly  reduced,  but  not  totally  elimi¬ 
nated  since  some  human  interaction  seems 
essential  as  well  as  appropriate.  The  result 
will  be  an  interactive  system  requiring  key 
inputs,  from  a  human,  of  the  kind  that  would 
be  considered  natural  for  human  understand¬ 
ing  of  what  a  program  and  its  suliparls  do. 
Much  or  all  of  the  necessary,  but  uninforma¬ 
tive,  details  will  be  handled  automatically. 

The  first  part  of  such  an  interactive  system 
is  already  operational  in  an  experimental  ver¬ 
sion  as  a  Lisp  program.  This  operational  part, 
called  a  verification  condition  giuierulor  |2:l|. 
takes  as  input  a  program  to  be  verified  and 
also  documentation  of  what  that  program  is 
to  do.  The  output  from  the  verification  condi¬ 
tion  generator  is  a  set  of  mathematical  lem¬ 
mas,  called  verification  conditions.  Proving 
these  lemmas  demonstrates  that  the  program 
is  consistent  with  its  documentation,  and 
hence  the  program  is  verified. 


Input  programs  to  the  verification  condition 
generator  are  written  in  Pascal  |18),  which  is  a 
precise,  modern,  Algol -like  programming  lan¬ 
guage.  Acceptable  input  programs  may  con¬ 
tain  assignment,  while,  conditional,  and  go-to 
sta>ements;  recursive  procedure  and  function 
definitions  and  calls;  and  one -dimensional  ar¬ 
rays.  Thus  a  powerful  subset  of  Pascal  is 
processed.  The  documentation  is  provided  by 
assertions  in  the  form,  roughly  speaking,  of 
quantified  Algol  Boolean  expressions.  The 
documentation  is  thus  a  slight  extension  of 
what  programmers  normally  use  to  state  con¬ 
ditions  on  computations  that  control  their 
programs. 

The  theoretical  basis  of  the  verification 
condition  generator  is  Hoare's  axiomatic  ap¬ 
proach  |.WU1]  for  defining  program  language 
semantics.  T1  >  semantics  are  given  by  means 
of  proof  rules  for  various  program  language 
constructs:  by  design,  this  facilitates  the  veri¬ 
fication  of  programs.  The  semantics  of  Pascal 
are  expressed  in  this  way  |.12|.  Formally,  a 
verification  is  a  demonstration  of  the  desired 
result  (consistent  documentation)  starting 
from  appropriate  mathematical  lemmas  and 
then  using  the  proof  rules.  The  verification 
condition  generator,  starling  from  the  known 
desired  result,  continually  computes  subgoals 
(works  backwards)  until  appropriate  lemmas 
are  computed.  These  lemmas  are  the  verifica¬ 
tion  conditions. 

The  verification  condition  generator  is  al¬ 
ready  a  useful  tool  in  verifying  programs. 
Numerous  examples  of  nontrivial  programs, 
including  published  algorithms  |.'t;t  .t'ij,  have 
been  verified  by  proving  by  hand  the  result 
ing  verification  conditions.  Of  greater  interest 
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and  usefulness  is  the  fact  that  several  arith¬ 
metic  and  array -sorting  programs  have  also 
been  verified  by  obtaining  proofs  of  the  veri¬ 
fication  conditions  using  an  existing  interac¬ 
tive  theorem  prover  { ;w> ).  Alter  human  input 
of  a  small  numljer  of  relevant  facts,  sue  h  as 
the  associative  laws  and  A  +  0  =  A,  and 
after  human  selection  of  overall  theorem - 
proving  strategies,  the  theorem  prover  pro¬ 
duced  its  proofs  without  further  interaction, 
in  one  case  involving  sorting,  the  theorem - 
prover  found  an  unplanted  error  in  a  hand 
proof,  and.  in  effect,  suggested  how  to  correct 
it. 

Future  Research 

Work  on  the  verification  condition  genera¬ 
tor  is  continuing  in  several  directions  which 
have  been  suggested  by  results  to  date. 
Changes  will  he  made  to  eliminate  the 
amount  of  detailed  human  effort  currently 
required.  A  capability  will  be  added  to  allow 
additional  proof  rules  to  be  specified  as  part 
of  the  input.  Additional  features  of  Pascal, 
especially  more  data  structures,  will  be  al¬ 
lowed  in  acceptable  input  programs.  The  most 
pressing  additional  capability  is  to  accommo¬ 
date  far  less  documentation  and  still  obtain 
verification  conditions  that  can  be  proved. 
Currently,  the  verification  condition  generator 
views  the  input  program  essentially  as  dis¬ 
joint  parts:  Iht  result  is  that  the  same  docu 
mentation  must  often  be  separately  specified 
for  each  part,  an  unnecessary  duplication.  Fi¬ 
nally.  much  of  what  has  been  accomplished 
for  Pascal  programs  is  easily  transferred  to 
other  languages.  I'he  verification  condition 
generator  may  be  extended  to  allow  other 
languages  as  input. 


Figure  4.2  Proposed  interaetiv, 
system  for  verifying  prcgvanc. 

The  success  with  the  verification  condition 
generator  suggests  additional  parts  of  the  in¬ 
teractive  system  for  providing  computer  as¬ 
sistance  in  verifying  programs.  The  overall 
plan  is  shown  in  Figure  4.2.  Programs  and 
documentation  are  input  to  the  verifii  ation 
condition  generator.  Before  attempting  to 
prove  the  resulting  verification  conditions,  it 
is  often  necessary  to  apply  algebraic  and  logi¬ 
cal  simplification,  and  more  generally,  simpli¬ 
fication  using  relevant  properties  of  the  oper¬ 
ations  in  the  input  program.  Such  .simplifica¬ 
tion  is  easy  to  do.  and  indeed,  many  of  the 
verification  conditions  are  proved  by  this  op¬ 
eration  alone.  The  verification  conditions  are 
very  shallow  mathematically  with  most  being 
absolutely  trivial  and  uninteresting.  Hence, 
mammoth  amounts  of  theorem -proving  capa¬ 
bility  are  not  needed.  Rather,  from  a  human 
viewpoint,  the  tediousness  and  error-prone  - 
ness  of  the  proofs  demand  the  assistance  ol 
the  theorem  prover.  The  analyzer  is  intended 
hi  tt'dutli  problems  given  to  the  .‘lunreui 
prover.  it  attempts  to  i.la  Ty  verification 
conditions  according  to  probable  methods  of 
proof  and  to  generate  simpler  subproblems  It 
can  also  be  used  to  find  the  "closest"  similar 
condition  that  is  provable  when  a  proof  ol  a 
given  condition  is  not  found,  ns  a  guide  to 
human  interucFon,  Since  these  approaches 
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have  been  used  to  obtain  both  hand  proofs 
and  proofs  using  the  interactive  theorem 
prover,  the  proposed  system  appears  to  have  a 
good  chance  of  being  developed  into  some¬ 
thing  truly  useful  for  software  assurance. 
(Collaboration  will  continue  with  D.  Luckham 
in  this  research.) 
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IXTRODUCTiOS 

The  ARPANET  has  clearly  demonstrated 
the  effective  sharing  of  distributed  computer 
resources.  Yet  the  principle^  exhibited  in  its 
design  have  broad  potential  for  improving  the 
Network  and  other  national  and  worldwide 
communications  systems  in  versatility,  reli¬ 
ability,  survivability,  and  cost -effectiveness. 
This  group  has  participated  in  the  research 
and  development  of  new  ARPANET  capabili¬ 
ties,  as  well  as  extending  the  earlier  work  of 
other  ARP  A  contractors. 

Project  Elements 

The  Network  program  comprised  the  fol¬ 
lowing  elements: 

Network  Conferencing 
Transparent  Network  Communications 
DOD  Communications  Study 
Accounting  System  Study 
Data  Reconfiguration  Service 
Portable  Terminals 

Seltcork  ('.onferencinp. 

The  main  thrust  of  ARPANET  capability 
explorations  to  date  has  been  in  the  area  of 
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computer  to  computer  data/program  commu¬ 
nication.  While  this  field  is  developing  impor¬ 
tant  new  concepts  in  data,  program,  and  other 
resource  sharing,  other  modes  of  communica¬ 
tion  are  necessary  for  the  general  needs  ot 
existing  and  future  telecommunications  sys¬ 
tems.  Specifically,  the  transmission  of  time- 
dependent,  continuous,  natural  information 
(such  as  speech)  represents  a  problem  area  for 
which  solutions  have  not  been  demonstrated. 

A  study  has  begun  here  of  some  of  the 
problems  associated  with  speech  communica¬ 
tion  via  the  ARPANET,  along  with  the  devel¬ 
opment  of  demonstrable  solutions.  Vocoding 
algorithms  (developed  by  other  ARPA  con¬ 
tractors)  and  appropriate  signal -  processing 
hardware  will  be  use' I  by  IS!  to  explore  the 
Network  voice  parameters  in  a  prototype  sys¬ 
tem  on  the  ARPANET  The  signal -processing 
hardware  will  also  lx?  used  to  simulate  the 
characteristics  of  various  types  of  networks. 
Conferencing  capabilities  will  later  be  ex 
tended  to  include  the  exchange  of  natural 
pictures  (such  as  scenes)  and  computer-de¬ 
rived  information. 


Preceding  page  blank 
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As  an  interim  measure  (until  high  -speed 
signal -processing  equipment  can  lx;  procured), 
a  network  simulator  has  been  written  fur  an 
in-house  STANDARD  Comp'  ler  Corporation 
IC-4000  computer.  D/A  and  A/D  converters 
have  also  l)een  attached  to  it.  With  this  con¬ 
figuration,  signal  stream  segmentation  is  pres¬ 
ently  being  studied. 

Transparent  \eltrork  Communications. 

The  overt  ARPANET  communication  in¬ 
structions  that  must  lx:  supplied  in  many  uses 
of  the  Network  tend  to  handicap  the  inexpe¬ 
rienced  user.  Transparent  networking  at¬ 
tempts  to  suppress  ARPANET  prot<x:ols  from 
the  point  of  view  of  the  user's  programs.  The 
means  of  achieving  remote  subroutine  access 
and  parameter  passing  are  being  studied.  The* 
goal  is  to  determine  the  requirements  of  cer¬ 
tain  classes  of  remote  process  communica¬ 
tions,  and  then  demonstrate  the  techniques 
developed  as  a  result  of  this  determination.  At 
the  moment,  various  interprocess  communica¬ 
tions  are  being  identified  and  classified  in 
preparation  for  demonstration  programs. 

1)01)  Communications  Study. 

A  study  was  initiated,  in  response  to  a 
1)( )D -ex pressed  need,  for  alternative  ap¬ 
proaches  to  the  consolidation  of  all  military 
message  communications  on  the  island  of 
Oahu.  Hawaii.  The  basic  goals  were  to  ini  - 
prove  service  and  lower  costs  using  advanced 
telecommunications  concepts.  The  proposed 
communications  system  plan  offers  both  a 
system  architecture  and  a  working  methodol¬ 
ogy  to  consolidate,  through  automation  of  the 
writer  to  reader  service,  the  Island's  message 
needs. 


.tccimaliug  System  Study. 

A  quick  response  study  drafted  an  AR¬ 
PANET  accounting  system  architecture  to 
provide  Network-wide  audit  and  accounting 
capabilities.  The  study’s  report  identified  re¬ 
sources  to  lx:  accounted  for  and  measurements 
to  lx:  recorded,  and  proposed  an  accounting 
system  design  and  implementation  milestones. 
An  A RPA -sponsored  group  is  now  investi¬ 
gating,  and  will  recommend,  an  accounting 
policy. 

Data  Heconji  purat  ion  Service. 

The  Data  Reconfiguration  Service  (l)RS),  an 
experiment  allowing  communication  between 
two  arbitrary  but  cooperating  remote 
processes,  has  ireen  completed  by  ISI,  the  Uni¬ 
versity  of  California  at  Santa  Barbara  (DCS If), 
and  The  Rand  Corporation.  The  DRS  permits 
a  user  to  specify  any  desired  data  transfor¬ 
mations  between  his  remote  processes  in  or¬ 
der  for  each  process  to  receive  data  in  ils 
expected  format.  The  two  processes  then  con¬ 
verse  as  if  they  were  directly  connected.  The 
DRS,  however,  monitors  their  dialogue  and 
performs  the  user -specified  transformations 
on  data  passing  between  them.  IS!  has  con¬ 
cluded  debugging  the  DRS  compiler  and  test 
mg  the  service.  DRS  is  now  offered,  on  an 
experimental  basis,  on  the  IBM  ;K>l)/7f>  at 
1ICSB. 

1‘orlaltle  Terminals. 

A  portable  terminal  for  use  with  the  AR¬ 
PANET  is  presently  being  develo|x:d.  Most  of 
the  capabilities  of  conventional  portable  dis 
play  terminals  will  he  available,  hut  this  pro 
lotype  will  he  huth  smaller  and  lighter  than 
existing  models.  The  case  will  fit  under  an 
airplane  seal  and  weigh  approximately  one 
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third  less  than  current  portables.  The  termi¬ 
nal.  using  an  acoustic  coupler,  will  lx?  con¬ 
nected  to  any  standard  telephone  handset  and 
will  communicate  from  there  to  any  AR- 
PANET  site.  Completion  date  for  the  proto¬ 
type  is  July  1.  1973.  If  this  model  is  successful, 
the  second  implementation  will  have  an  in¬ 
creased  character  display,  an  optional  graph¬ 
ics  capability,  and  lie  even  smaller  in  weight 
and  size. 

\ETWORK  C()\FERESCI\G 

This  subproject  is  investigating  the  prob¬ 
lems  of  multiple  site  intercommunications 
through  a  network  such  as  the  ARPANET. 
The  current  research  scope  includes  the  feasi¬ 
bility  of  secure,  high  quality,  low  hit  rate, 
digital  voice  communications  via  a  packet - 
switched  network,  in  addition,  human -factors 
considerations  involved  with  communicating 
via  this  medium  will  be  investigated.  Image 
transmission,  conference  protocol,  interaction 
of  conferencing  requirements,  and  computer/ 
data  file  support  will  he  explored  later. 

Mvticork  Conferencing  Tasks 

The  tasks  of  the  network  conferencing  sys¬ 
tem  are: 

1)  To  establish  a  wide  bandwidth  Pail -du¬ 
plex,  high  quality,  real  time,  voice  link:  this 
will  he  done  first  with  the  1C -4000  simulating 
the  ARPANET.  This  equipment  permits  study 
of  the  human -factors  elements  of  continuous 
signal  stream  segmentation  over  a  store  and  - 
forward,  packet -switched  network. 

2)  To  implement  a  Pulse  ('.ode  Modulation 
(PCM)  voice  link  on  the  [('.-4000.  Speech  will 
he  sampled  at  a  rati'  of  0,000  times  per  second, 
and  then  quantized  using  0,  7,  or  H  hits.  This 
results  in  a  hit  rate  of  48.  r>(>.  or  04  kilobits  per 


second.  A  nonlinear  quantization  scheme  will 
be  used  to  achieve  the  best  overall  signal -to- 
noise  ratio  without  increasing  the  sampling 
frequency  and/or  the  number  of  quantizing 
levels. 

3)  To  implement  nonreal -time  experiments 
with  existing  Linear  Predictive  (Coding  (LPC) 
bandwidth  reduction  techniques  on  the  1C- 
4000.  This  will  be  done  to  gain  an  under¬ 
standing  of  both  the  computation  require¬ 
ments  for  real  time,  low  bandwidth  LPC,  and 
the  effects  of  LPC  on  speaker  identity  and 
intelligibility. 

4)  To  implement  a  signal  processor  system 
capable  of  simulating  the  ARPANET,  as  well 
as  other  digital  networks,  while  processing 
LPC  algorithms  for  low  bandwidth,  reel  time, 
full-duplex,  voice  communications. 

5)  To  implement  an  ARPANET  simulator 
and  LPC  algorithms  on  the  signal  processor. 
Continuous,  real  time  speech  will  he  seg¬ 
mented  as  required  by  the  asynchronous  na¬ 
ture  of  the  ARPANET,  or  other  digital  net¬ 
works.  Once  bandwidth  has  been  reduced, 
methods  of  assuring  continuity  and  natural - 
sounding  speech  will  be  studied.  These  exper¬ 
iments  will  buffer  speech  samples  to  assure 
continuity  of  speech  over  network  dropout 
intervals  and  over  different  path -dependent 
transmission  delays. 

(>)  To  imp.  :mcnt  multiple-site  voice  com¬ 
munications  when  practical  network  band¬ 
width  has  been  achieved.  It  is  assumed  that 
another  processor  will  exist  on  the'  AR¬ 
PANET  and  that  algorithms  implemented  on 
the  ISI  signal  processor  can  lie  exported  for 
dual  site  experimentation. 
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7)  To  losl  conierencmg  situations.  including 
working  distributed  office  communications, 
small  technical  conferences.  and  decision  ses- 
sions  (such  as  with  Ihe  Delphi  method). 

ii)  To  examine*  the  broader  conferencing 
problem  involved  in  multiple  inert  a  commu¬ 
nications.  such  as  slow  frame  ’■  V  or  snapshot 
imaging.  and  remote  hard  cop;  or  l.icsimile,  A 
terminal  will  lie  developed  uicnrpnrating 
these  mullimediii  communications  devices 
which  expand  shared  information  space.  Ad¬ 
ditional  scenarios  will  he  generated  as  these 
tools  are  added  to  Ihe  terminal. 

ExfHTiniriiln I  (  onjif'ii rn / inn 

A  wide  bandwidth,  lull-duplex,  voice 
channel  to  a  STANDAKI )  ( lompulcr  ( lor  porn  - 
lion  1(1  41)01)  microprogram  computer  has 
been  implemented  This  implementation  was 
selected  primarily  because  of  the  availability 
ol  the  in-house  Id -4000  processor  on  a  dedi¬ 
cated  basis.  The  configuration  will  be  used  to 
simulate  ARPANET  message  delays  and  their 
effects  on  continuous  voice  communication 
I  he  channel  bandwidth  is  5kl  I/,  (about  25". 
wider  than  the  standard  telephone  bandwidth 
of  4k I  Iz. ).  anil  no  bandwidth  compression 
techniques  are  ii;  mI.  The  system  employs  an¬ 
alog  to  digital  and  digital  to  analog  converters 
with  0  hit  resolution  and  a  100  //sec  conver¬ 
sion  rate  The  total  digital  hit  rate  is.  therefore. 
ttOk  bits. 

The  experimental  configuration  involves 
two  sound  booths,  each  with  a  high  quality 
speaker  and  microphone  (to  maintain  control 
over  quality  ait  i  I  nets):  this  setup  allows  the 
experimenter  to  communicate  as  lie  would 
over  a  lull  duplex  speaker  phone.  The  expel' 
imenler  s  voice  is  amplihed  from  Ihe  micro 
phone,  hllered  by  a  b  pole,  low  pass  Idter  at 


f»kl  I/.,  and  passed  through  Ihe  A/D  converter 
to  Ihe  1(1-4000.  Similarly.  Ihe  second  experi¬ 
menter's  voice  is  amplified,  filtered,  and 
passed  into  Ihe  1(1-4000.  The  1(1-4000  then 
simulates  Ihe  delays  which  would  be  encoun¬ 
tered  if  Ihe  s|>eakers  were  conversing  over  the 
ARPANET.  Alter  Ihe  proper  delay  lime.  1  hi 
1(1  4000  sends  Ihe  shakers  digitized  voice  to 
the  opposite  experimenter  s  D/A  converter, 
then  through  another  filler,  the  power  ampli¬ 
fiers.  and  Ihe  s|x.*akers  in  Ihe  sound  Ixxilhs. 

.  I  /v  /*,  I  \  /, 7’  Simulation 

The  ARPANE'I  audio  simulator  operates 
(inner  control  of  an  1(1-4000  microprogram. 
The  microprogram  emulates  an  1HM  7044 
computer  with  an  extended  instruction  set. 
An  extended  version  of  IHM’s  7044  1RSYS 
provides  Ihe  basic  target  machine  software 
support. 

The  simulator  can  he  driven  by  two  audio 
channels.  The  audio  signal  is  read  and  written 
at  Ihe  rale  of  00  hits  per  channel  every  400 
microseconds,  and  synchronized  In  interrupts 
Imm  Ihe  analog-digital  interface.  Due  to  Ihe 
limited  speed  capability  of  the  1(1-4000,  Ihe 
interrupt  service  routine,  although  carefully 
(.oiled,  uses  about  05').,  of  Ihe  (1PU  cycles.  The 
remaining  lime,  while  not  enough  to  allow 
extensive  processing  on  a  word  by  word  basis, 
permits  simulation  of  Network  delays.  The 
data  is  packet ized,  and  both  data  and  ready  - 
for  next  message  (Kl’NM)  transmission  de¬ 
lays  are  appropriately  inserted  in  each  chan 
nel.  Network  delays  are  call  dialed  according 
to  formulas  reported  by  McQuillan  el  al.  |/|. 
t ’p  to  5  seconds  of  speech  can  he  buffered  by 
the  K  4000  for  each  channel.  In  addition, 
some  periods  ol  silence  can  he  delected  and 
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eliminated  thus  reducing  the  average  band¬ 
width.  In  the  absence  of  ARPANET  delays, 
speech  quality  is  ! letter  than  that  on  the  tele¬ 
phone.  and  full-duplex  operation  has  lieen 
achieved. 

The  Network  simulation  code  has  lieen  im¬ 
plemented  as  have  the  hardware  A/I)  and 
l)/A  converters.  The  LPC  speech  analysis  and 
speech  segmentation  are  planned  for  the  fu¬ 
ture. 

I  iH-ixIrrs  mill  I  ih  ihUii"  Technu]iu,!i 

A  field  study  was  conducted  to  determine 
the  state  of  t ht?  art  of  vocoders  and  vocoding 
techniques.  Five  possible  sources  of  vocoders 
were  found: 

1)  Svlvania  markets  a  minicomputer,  the 
Programmable  Signal  Processor,  capable  of 
Fast  Fourier  Transforms  (FFT)  and  currently 
programmed  for  real  lime  Cepstrum  encoding 
at  2.4  kilobits.  Intelligibility  is  about  9f»%.  and 
the  cost  for  a  two  site  system,  with  availabil¬ 
ity  six  months,  would  lie  SBO.(KK) -S ITitKOtKl. 

2)  LTV  Elect rosvstems.  Inc.  offers  a  channel 
vocoder  that  operates  at  2.4  or  4.8  kilobits  and 
uses  a  regular  telephone  handset.  The  a'  ula 
bility  of  such  a  vocoder  is  three  months  and 
the  system  cost  is  about  $17, ()()()  per  site. 

It)  Magnavox  has  a  2.4  to  4. ft  kilobaud 
modem  for  attachment  to  a  discrete  FFT  vo¬ 
coder.  A  prototype  is  available  and  a  two  site 
system  would  cost  $2ft.()()(). 

4)  Phileo  Ford  offers  a  voice -excited,  analog 
vocoder  that  operates  at  9.6  kilobaud.  It  costs 
approximately  $20,000  per  uni!  and  intelligi¬ 
bility  is  about  10-20'!..  better  than  channel 
vocoders.  They  also  have  a  Continuous  Vara- 
hlc  Slope  Delta  Modulation  Technique  at  10 
kilobaud  that  exhibits  good  recognition  with  a 


26-30  decibel  signal -to -noise  ratio.  An  analog 
implementation  is  available  now;  a  digital 
version  will  lx?  available  srxin.  System  cost  is 
approximately  $2,000  per  site. 

r»)  Lincoln  Labs  has  developed  a  digital 
pitch  vocoder  at  2.4  kilobits  and  a  rack¬ 
mounted  voice-excited  vocoder  at  4.8  to  9.6 
kilobits.  These  could  possibly  Ih:  loaned  to  IS! 
for  experimentation. 

6)  Several  sites*  are  studying  LPC  tech¬ 
niques  for  speech  understanding  but  an;  at 
least  a  year  away  from  2.4  kilobits,  real  time, 
high  quality  vocoders. 

Stair  of  i Iw  In. 

The  field  study  on  vocoders  and  associated 
techniques  produced  the  following  conclu¬ 
sions  which  will  lx:  used  in  the  project's  work 
when  a  signal  processor  is  obtained: 

•  No  high  quality  hardware  vocoder  exists 
at  2.4  kilobaud  or  lower. 

•  No  real  time,  high  quality  software  vo¬ 
coder  exists  for  the  same  bandwidth. 

•  Because  of  the  poor  speech  quality  of  the 
available  vocoders,  it  would  be  unwise  to 
procure  a  hardware  vocoder  for  ARPANET 
experiments  at  this  time. 

•  A  signal  processor  would  allow  much 
more  flexibility  in  algorithm  manipulation 
and  network  simulation  than  would  a 
hardware  vocoder. 

•  A  software  vocoder  allows  any  imple¬ 
mented  algorithms  to  be  shared  among  AR 
PANF.T  conferencing  experimenters. 


Unit  ibT.mi’k  .in-1  \»-wnbtn  hit  .  !  'mnsilv  nl  I  t«i h .  Southern 
Mrlhtnlisi  I  niuTsilv.  N.thnn.il  Smml\  Ntft'nt  v,  S|)t*t*i  hi  ,nm 
liiiifitt  <it  tofts  RfM’.irt  h  Lthoi.iloi  v .  Ini 
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•  LIT  is  most  likely  to  pnxluce  high  qual¬ 
ity  speech  at  reasonable  bandwidth,  although 
present  algorithms  are  not  computationally 
practical. 

•  Project  personnel  will  implement  LIT 
algorithms,  as  they  are  developed  by  the 
speech  research  community.  The  signal 
processor  necessary  for  vocoding  algorithm 
implementation  will  also  support  network 
simulation  for  controlled  study  of  Network 
effects  under  various  conditions. 

Initial  Study  of  I.PC.  of  Speech 

A  preliminary  study  was  made  to  deter¬ 
mine  the  computational  requirements  lor  a 
signal  processor  which  is  capable  of  providing 
and  maintaining  high  quality,  full-duplex 
voice  communications  over  the  ARPANET. 
Current  efforts  are  directed  towards  the  Lin- 
ear  Predictive  Coding  (LPC)  s|jeech  processing 
algorithms. 

The  theory  of  various  forms  of  linear  pre¬ 
diction  has  been  treated  in  d(  ;|  in  the  litera¬ 
ture  (2 - lf>).  Several  formulations  of  the  tech¬ 
nique  are  closely  related  but  they  have  im¬ 
portant  differences.  One  aspect  common  to  all 
formulations  is  that,  at  a  particular  time,  a 
speech  sample.  s(nT).  can  be  approximated  by 
a  weighted  sum  of  the  post  p  samples  as 

s(nT)  ?  1  a^s(nT-kT) 

i<=i 

where  T  is  the  sampling  interval,  p  is  an 
integer  between  10  and  15.  and  aks  are  coef¬ 
ficients  closely  related  to  the  glottal  excitation 
function  and  the  vocal  tract  transfer  function 
of  the  human  speech  mechanism.  I'he 
weights.  aks,  referred  to  as  the  predictor  co¬ 
efficients.  are  calculated  to  minimize  the  aver  - 
age  energy  in  the  error  signal  (which  repre¬ 
sents  tin  difference  between  the  actual  and 


predicted  speech  amplitude).  The  coefficients 
are  calculated  over  short  speech  segments  of 
10-30  milliseconds,  and  thus  change  as  the 
speech  statistics  vary. 

1’he  error  signal  can  lx;  characterized  by  its 
total  energy  and  a  time  distribution  of  either 
periodic  pulses  at  the  pitch  rate  or  white 
noise,  depending  on  whether  the  speech  is 
voiced  or  unvoiced  Thus,  in  an  LIT  system, 
the  error  signal  is  not  transmitted  as  in 
adaptive  predictive  ccxling  J 2 j.  but.  rather,  its 
time  and  energy  characteristics  are  transmit¬ 
ted. 

m.  Speech  Processing  System 

An  LIT  speech  processing  system  consists 
of  an  analyzer  at  the  transmitting  site,  and  a 
synthesizer  at  the  receiving  site.  At  the  trans 
milling  site,  short  segments  of  speech  are 
analyzed,  i.e.,  the  predictor  coefficients  are 
computed,  the  pitch  is  extracted,  and  the 
voiced/unvoiced  decision  is  made  either  on 
the  speech  or  error  signal.  At  the  receiving 
site,  a  reconstruction  filter  is  formed  (excited 
by  the  error  signal)  and  gives  an  approxima¬ 
tion  of  the  speech  signal  as  its  output.  Thus, 
the  synthesizer  need  only  know  the  predictor 
coefficients  and  gain  factor,  the  vocal  pilch, 
and  a  voiced /unvoiced  decision  parameter,  in 
order  to  generate  an  approximation  of  the 
error  signal  which  excites  the  reconstruction 
filler. 

Various  forms  of  LIT  speech  processing 
systems  have  evolved  which  differ  in  the 
method  of  compulation  of  the  predictor  cue  I 
freients.  the  method  of  pitch  extraction,  and 
the  voiced /unvoiced  decision.  Another  impor 
taut  factor  is  the  transmission  parameters. 
Transmission  of  the  predictoi  coefficients  re¬ 
quires  at  least  f(  to  t()  Inis  per  coefficient  in 
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order  to  insure  the  stability  of  the  reconstruc¬ 
tion  filter  |;j).  Therefore,  transmission  of  an 
equivalent  set  of  parameters  must  lie  consid¬ 
ered.  This  transmission  can  lie  done  hy  partial 
correlation  (PARCOR)  coefficients,  area  func¬ 
tions.  or  frequencies  and  bamhvidths  of  the 
poles  of  the  roconst ruction  filter.  The  set  of 
PARCOR  coefficients  is  Ixiing  considered  here. 
At  the  receiver  site,  speech  samples  are  ob¬ 
tained  directly  from  these  parameters  or  via 
the  predictor  coefficients. 

/,/'(.  Speech  Pros'essinp  System 
Information  Rate 

The  information  rate  of  the  L.PC  speech 
processing  system  is  given  hy 

R  =  (\p  +  \.  4-  \\  +  Y)/T,  (bits/second) 
where 

Np  =  l  Y 

is  the  number  of  hits  assigned  to  the  predictor 
coefficients  or  any  other  related  parameters 
(such  as  PARC, OR  coefficients).  Nr  is  the  num¬ 
ber  of  hits  for  the  pitch  |x:riod:  N,  and  Nt.  are 
the  nil  ml  xt  of  hits  for  the  voiced /unvoiced 
decision  and  the  gain  factor,  respectively.  T,  is 
the  frame  period  to  readjust  all  the  parame¬ 
ters  and  T,  =  1/T,  is  the  frame  rate  (in  fra¬ 
mes  second).  For  example,  if  a  total  of  72  hits 
are  used  for  transmitting  all  the  parameters, 
mid  il  the  frame  period  is  10  milliseconds  (i.e., 
100  frames  per  second),  then  the  resulting  hit 
rate  is  R  =  7,200  bits/ second.  In  order  to 
achieve  speech  transmission  at  2.4  kilobits,  all 
the  parameters  represented  hy  72  hits  must  he 
readjusted  every  ill)  milliseconds. 

experiments  have  shown  that  the  follow¬ 
ing  hit  assignment  is  satisfactory  for  various 
control  parameters  of  the  LPC  synlhe.siy.er: 


N,  =  60,  \',=  6.  N,  =  1.  and  \„  =  5,  re¬ 
sulting  in  a  total  of  72  hits. 

Computational  Requirements 

Computation  and  storage  requirements  for 
a  linear  predictive  speech  coding  system  de¬ 
pend  on  the  particular  scheme  used  in  com¬ 
puting  the  predictor  coefficients,  and  the 
method  of  pitch  extraction  and  voicing  deci¬ 
sion,  among  other  factors.  If  the  coefficients 
are  obtained  hy  covariance  techniques  |.i|,  and 
sophisticated  pitch  extraction  algorithms  are 
used,  then  the  total  number  of  computations 
(a  computation  is  defined  as  one  multiplica¬ 
tion  and  one  addition)  could  he  as  high  as 
9.225  for  each  frame  |lf>|.  For  a  hit  rate  of  2.4 
kilobits/second,  if  the  frame  length  is  50  mil¬ 
liseconds  (see  LPC  Speech  Processing  System 
Information  Rate  above),  then  the  total  ntim- 
lx>r  of  computations  is  307.500  per  second:  this 
implies  that  each  computation  must  he  per¬ 
formed  in  3.25  microseconds.  Accuracy  studies 
indicate  that  such  a  speech  processor  will 
maintain  high  quality  voice  if  calculations  are 
performed  with  a  floating  point  precision  of  a 
16  hit  mantissa  and  an  6  hit  exponent. 

Various  researchers  are  presently  in  esli- 
gating  the.  possibility  of  successful  operation 
of  an  LPC,  speech  system  with  a  fixed  point 
processor.  Reducing  the  total  number  of  com¬ 
pulations  is  also  being  investigated  |17|.  These 
techniques  will  he  studied  and  some  will  lx: 
implemented  on  the  signal  processor,  when 
the  latter  is  obtained. 

TRA  \St>  I  RE\ 7  V  /  /  II  ORK 

(<}M\n\i<trio\s 

The.  ARPANKT  has  hiougbt  to  the  fore  the 
general  problems  of  communication  among 
programs  residing  on  different  machines.  '1  Ins 
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subproject  investigates  means  for  calling  pro¬ 
grams  over  the  ARPANET  (i.e..  from  outside 
of  their  host  machine  environment)  in  a  man¬ 
ner  transparent  to  the  user.  For  example,  a 
user  of  a  list  processing  system  might  need  an 
arithmetic  computation  capability  better 
suited  for  another  language;.  Similarly,  a  pro¬ 
gram  could  provide  access  to  specialized  data 
bases  as  well  as  to  special  operations  on  that 
base.  In  these  instances,  it  is  desirable  for  one 
program  to  invoke  another  as  a  subroutine.  In 
principle,  the  programs  need  not  reside  on  the 
same  host:  thus  they  may  be  distributed 
among  several  machines  on  the  ARPANE  T. 

Trail simmi I  A rt working  Tasks 

Project  tasks  are: 

1)  To  determine  the  requirements  for  pro¬ 
grams  that  provide  transparency  for  pro¬ 
gram  to  program  coupling.  Such  require 
merits  are  of  two  kinds: 

a)  language-independent  considerations 
(e.g..  the  protocol  between  programs  for 
passing  parameters  and  other  data):  and 

h)  language -dependent  considerations  in¬ 
volved  in  implementations  for  particular 
language  classes  (e.g..  Lisp  and  PI, /I). 

2)  To  develop  example  programs  that  dem¬ 
onstrate  the  utility  of  the  proposed  tech¬ 
niques. 

The  requirements  are  being  examined  in 
terms  of  the  conversion  and  transmission  of 
data  among  programs  residing  on  different 
machines,  and  the  simulation  of  programs' 
address  spaces  with  regard  to  passing  param¬ 
eters  lx  tween  them.  A  literature  review  of 
techniques  t  nrrently  used  for  data  conversion 
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and  transmission  (especially  those  used  on  the 
ARPANET)  is  being  conducted.  A  systems 
analysis  of  the  requirements  imj  osed  by  the 
Network  upon  transparent  prog:  irr  interac¬ 
tions  is  also  being  made. 

When  the  requirements  are  ascertained, 
program  to  program  communication  for  sev¬ 
eral  systems  will  lx;  implemented. 

Data  (onirrsian  anil  Transmission 

Methods  for  dealing  with  the  problem  of 
data  conversion  and  transmission  ire: 

1)  use  a  common  facility,  such  as  the  Data 
Reconfiguration  Service  (DRS),  to  accom¬ 
plish  the  necessary  conversion:  and  trans¬ 
missions: 

2)  implement  particular  protocols  for  trans¬ 
mitting  data  between  any  two  machines: 

2)  use  some  common,  data-tram for  protocol 
for  expressing  all  data  in  an  intermediate, 
standard  form,  where  each  host  ;s  responsi¬ 
ble  for  just  the  transformations  to/from  this 
intermediate  form. 

The  DRS  (see  that  section  below)  is  cur¬ 
rently  being  offered  as  an  experimental  facil¬ 
ity  at  the  University  of  California  at  Santa 
Barbara  |l«|.  While  this  is  a  possible  interim 
solution,  it  is  no!  viable  in  the  long  run  for 
performance  reasons  unless  implemented  in 
firmware. 

The  second  method  is  t hi;  most  common 
technique,  with  two  sites  using  an  agreed 
upon  nonstandard  scheme. 

The  third  procedure  is  considered  a  sub¬ 
stantial  part  of  a  viable  transparent  interpro 
gram  communication  system.  It  avoids  the 
availability  and  delay  problems  inherent  in 
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using  a  third -parly  system  for  data  conver¬ 
sion,  and  does  not  suffer  from  the  incompati¬ 
bilities  and  multiplicity  of  effort  prevalent  in 
the  second  method. 

Transneft  cor  ft  Parameter  Passing  and 
Address  Simulation 

The  prohlem  of  transparent  communication 
through  address  space  mapping  has  not  Ireeu 
examined  except  in  cases  of  programs  com¬ 
municating  through  a  shared  (actual)  address 
space  1 19.20]  on  a  single  machine. 

Briefly,  the  problem  is  to  determine  that  a 
program.  A,  has  at  some  point  attempted  to 
access  a  variable  thal  exists  in  the  address 
space  of  another  program,  B,  and  thus  access 
to  that  space  must  occur  (e.g„  a  variable  called 
by  name).  Upon  recognizing  the  variable- 
name  reference,  the  appropriate  access  must 
be  effected.  Program  B  need  not  be  either 
directly  used  or  invoked  by  program  A;  i.e„  B 
could  have  called  C  which  in  tun,  called  A.  so 
that  B's  actual  parameters  have  filtered 
through  to  A  by  way  of  C. 

The  problem  can  be  partitioned  as  follows: 
1)  determine  that  a  transparent  network  pro¬ 
gram  call,  or  data  transfer  pursuant  to  a  call 
(i.e„  passing  of  parameter  values,  etc.)  is 
needed:  2)  establish  connections  to  effect  the 
call  or  transfer:  11)  invoke  the  procedures  for 
effecting  the  call  or  transfer. 

1)01)  cornu  XICATIOXS  ST l  l)\ 

This  subproject  is  an  integral  part  of  AK- 
I’A's  and  ISl's  program  to  explore  the  utilize 
linns  of  computers  and  communications  re¬ 
sources  applicable  to  military  environments. 
The  task  may  be  characterized  as  assisting 
tie  (juTatuinal  arms  or  IMH)  in  rupiUdi/ing 


on  its  research  products  provided  by  ARPA. 
Within  this  framework,  the  specific  goal  of 
this  study  was  to  introduce  an  advanced  tele¬ 
processing  architecture  into  a  IX)D  opera¬ 
tional  environment  to  substantially  reduce 
message -handling  costs  and  delays, 

A  sizable  complex,  namely  the  IX)I)  com¬ 
munications  facilities  and  methods  on  the 
island  of  Oahu.  Hawaii,  was  examined.  Care¬ 
ful  consideration  was  given  hoth  to  the  cur¬ 
rent  operations  on  Oahu  and  the  projected 
requirements.  This  data  gathering  was  fol¬ 
lowed  by  a  report  |2l]  recommending  a  tele¬ 
communications  system  architecture  and  phi¬ 
losophy  of  operation. 

The  suggested  communications  and  com¬ 
puter  components  are  production  items 
within  a  customized  configuration  suited  to 
present  needs.  The  aTchiteotine  allows  lui 
addition  or  deletion  of  components  to  accom¬ 
modate  future  requirements  The  use  of  off- 
the-shelf  units  would  allow  the  system  to  lie 
operational  within  two  years  at  a  cost  of 
approximately  $25  million. 

Briefings  on  the  conclusions  and  recom¬ 
mendations  in  the  report  were  provided  for 
military  communications  officers  responsible 
for  the  Pacific  area. 

Current  Situation 

To  assure  an  adequate  level  of  understand¬ 
ing  of  need.  1S1  staff  members  visited  Hawaii 
in  March  and  April,  conducted  interviews 
with  1X)1)  staff  both  in  Oahu  and  in  Wash¬ 
ington.  I ).( '..  and  used  the  results  of  data  oh 
lained  from  the  Commander  in  Chief,  Pacific 
(CINCPAC). 

Military  communications  on  the  island  of 
tabu  aie  handled  by  ,'MMMI  nimuuracations 
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personnel  trained  in  the  handling  and  distri¬ 
bution  of  messages.  They  currently  provide 
the  interface  lietween  the  people  who  wish  to 
send  and  receive  messages  and  the  local  com¬ 
munications  equipment.  The  cost  of  this  serv¬ 
ice  is  about  $20  million  per  year. 

Though  needs  of  the  various  organizations 
and  sites  on  the  Island  are  reasonably  com¬ 
mon.  limitations  of  the  manual  system  require 
that  message  functions  frequently  be  dupli¬ 
cated.  Furthermore,  within  each  organization, 
several  stages  of  manual  message  accounting, 
copying,  and  courier-forwarding  exist  be¬ 
tween  the  electronic  communications  and  the 
action  officer.  For  most  action  officers  then?  is 
no  secure  communication  means,  other  than 
hand  routing,  to  coordinate  messages  either 
for  preparation  or  for  action. 

This  manual  handling  results  in  high  com 
municntions  costs,  great  inconvenience,  and 
often  very  long  delays  in  message  preparation 
and  delivery.  For  these  reasons,  the  current 
message  service  is  largely  treated  as  a  mail 
service,  rather  than  a  prompt  message  means. 
To  lower  costs  and  delays,  the  number  of 
communications  personnel  must  be  reduced 
by  automation  of  their  accounting  and  routing 
functions,  and  by  providing  direct  communi¬ 
cations  capability  to  the  offices  of  message 
senders.'  receivers. 

I  HI*  IA/-.’7  I  rrhitvrtnrr 

The;  particular  system  a.chiteolure  pro¬ 
posed  in  the  report  is  based  on  operational, 
stale  of  the  art,  message -handling  compo¬ 
nents.  The  recommended  ARPANET  technol¬ 
ogy  is  currently  used  productively  by  project 
administrators,  coordinators,  technical  mail 
agers.  liaison  personnel,  and  secretaries,  lor 
theii  daily  communication  needs. 


The  ARPANET  architecture  was  suggested 
lie ‘cause  several  hundred  man-years  of  R  &  D 
have  been  invested  in  its  various  components. 
Very  little  additional  effort  would  be  required 
to  customize  this  architecture  for  military 
ntxnls  and  environments.  Technically,  this  en¬ 
tire  system  could  Ik?  operational  in  less  than 
24  months. 

1. lists. 

The  system  can  he  installed  for  an  esti¬ 
mated  investment  of:  20  to  40  man -years  and 
a  few  million  do  inrs  for  system  component 
modification;  approximately  $2$  million  in 
capital  costs:  and  $200,000  per  year  for  leased 
line  costs.  It  would  provide  Oahu -wide,  con¬ 
solidated.  direct  writer  to  reader  automation, 
which  would  result  in  large  savings,  a  signif¬ 
icant  increase  in  the  efficiency  of  action  of¬ 
ficers.  and  a  vast  improvement  in  message 
promptness.  However,  if  a  new  system  is  de¬ 
signed  from  the  beginning,  costs  in  excess  of 
$50  million  can  easily  lie  expected,  with  a 
final  system  delivered  in  three  to  five  years. 

Tvchnolofiy  anil  \tclho<lolof>\  . 

It  was  determined  that  not  only  a  technol¬ 
ogy.  but  also  a  methodology  was  needed  to 
promote  a  smooth  transition  from  the  present 
manual  arrangement  to  a  largely  automated, 
reliable,  and  cost  effective  system.  The  report 
suggests  a  well -proven  system  architecture 
and  u  functional  methodology;  it  is  emphati¬ 
cally  felt  that  the  two  are  inseparable  if  an 
effective,  user  oriented  system  is  to  be  con¬ 
st!  eMed. 

h.yjiaialahli'  System. 

Although  the  principal  focus  of  the  study 
was  the  solution  of  the  Oahu  communications 
problem,  the  system  should,  at  the  same  time. 
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be  viewed  in  larger  context.  Since  the  pro¬ 
posed  communications  architecture  is  rela¬ 
tively  independent  of  physical  area  and  of 
number  of  users  served,  the  Oahu  solution 
might  serve  as  a  prototype  for  other  similar 
sites;  it  can  also  serve  in  expanded  form  as  a 
worldwide  military  communications  system. 

The  basic  system  architecture  can  accom¬ 
modate  new  services  and  easily  expand  or 
contract  without  disruption  of  ongoing  opera¬ 
tions.  Thus  the  Oahu  military  community 
will  not  be  constrained  by  a  specific  mecha¬ 
nism  for  their  current  mode  and  level  of  op¬ 
eration, 

(hi-litie  System 

To  fully  realize  the  cost  and  functional 
benefits  of  an  automated  system,  it  is  essential 
that  on-line  terminal  communication  be 
brought  directly  to  the  action  officer  and/or 
his  secretary.  This  will  not  requi-e  a  terminal 
for  every  officer  on  the  Island,  since  in  most 
cases  several  officers  and  support  personnel 
are  clustered  in  a  single  physical  office  space. 
Their  traffic  levels  are  such  that  several  ol  - 
ficers  (average  of  :i)  can  share  a  terminal 
without  conflict,  Ily  allowing  these  people  to 
be  directly  on-line,  the  system  can  provide; 
complete  accountability  of  messages;  prepara¬ 
tion  aids;  scanning  aids:  iutoruduv  unmount  - 
cation:  message  status  reporting;  task  listing 
by  priority,  with  audible  and  visual  alarms, 
and  many  other  personnel  aids  to  enhance  the 
effectiveness  of  action  officers. 

bringing  the  coiniiiunications  directly  to 
the  user  offers  a  far  reaching  set  of  capahili 
ties  that  extend  beyond  anything  currently 
available  and  uitii  mole  complete  secitiiU 
protection.  Not  only  are  delay  limes  of  only 


seconds  attainable,  but  the  possibility  for  in¬ 
formal  interterminal  communications  can  im¬ 
prove  the  operation  of  a  unit  and  greatly 
improve  security. 

/f.  \  f.  \  nml  \lul tics. 

Two  systems,  TENEX  and  Multics,  have 
already  been  developed  and  made  operational. 
These  systems,  in  essence,  perform  this  kind 
of  message  service  today.  The  TENEX  system, 
based  on  the  Digital  Equipment  Corporation 
(DEC)  PDP-10.  provides  a  message -handling 
service  on  the  ARPANET;  Multics,  based  on  a 
Honeywell  6180.  provides  a  capability  for 
handling  messages  and  for  multilevel  security 
safeguards.  Either  of  these  systems  is  capable 
of  effectively  supporting  the  communications 
requirements  for  Oahu.  Software  development 
is  needed  to  tailor  the  system  to  the  specific 
requirements  of  the  users  of  Oahu.  However, 
fundamental  changes  to  the  underlying  oper¬ 
ating  system  structure  are  not  required, 

1‘inkcl-sicilihinfi 

A  reliable  communications  system  is 
noeded  to  interface  (he  users  to  these  ma¬ 
chines.  The  interconnection  should  he  such 
that  the  users  are  totally  unaffected  by  the 
failure  of  an  individual  computer  and  its  lo¬ 
cation.  The  ARPANET  packet -switching 
technology  is  extremely  well  matched  to  this 
kiwi  uf  perfnrmuiui*  Although  other  forms  ul 
communications  can  serve  to  interconnect  the 
user  and  computers,  the  packet  switching  ap 
plwatiun  has  t*vu  U  teased  in  this  plan 
because  it  is  more  reliable  and  more  flexible 
in  serving  a  wide  variety  of  users  and  user 

Herds,  further.  Mtr.  s\stettl  e,  in.silv  sea)  able  in 
size. 
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(ienernl  Services  \eticork. 

Communication  of  separate  intelligence 
community  traffic  through  a  general  services 
network  is  easily  achieved.  The  network  ar¬ 
chitecture  proposed  is  flexible  enough  tu  ex¬ 
tend  to  any  capacities  that  cun  be  reasonably 
foreseen  in  the  near  future,  Further,  the  pro¬ 
posed  system  permits  the  interconnection  of 
computers  to  provide  other  services.  Also,  the 
network  can  be  easily  interfaced  to  other 
communication  systems  (i.e.,  AUTODIN)  for 
worldwide  connectivity. 

The  Report 

The  report  develops  this  plan  in  greater 
detail.  It  describes  the  communications  prob¬ 
lem  on  the  island  of  Oahu,  discusses  the  na¬ 
ture  of  the  user  requirements  and  shows  how 
desirable  arid  workable  is  the  objective  of 
placing  the  user  direcMy  on-line,  proposes  an 
overall  system  and  describes  its  operation, 
covers  the  magnitude  of  the  system  required, 
and  describes  detailed  cost  and  implementa¬ 
tion  considerations. 

Briefly,  then,  the  report  describes  a  plan  for 
consolidation  of  communications  services  on 
Oahu  which  relies  on  placing  the  users  di¬ 
rectly  in  contact  with  an  automated  message¬ 
handling  service.  This  service  would  lx:  pro¬ 
vided  by  a  set  of  computer-based  message 
processors  configured  In  provide  message 
handling  with  security  capability  and  high 
reliability.  These  processors  would  be  inter¬ 
connected  with  each  other  and  the  users  via  a 
packet -switching  network.  The  entire  system 
would  provide  essentially  ‘  immediate  (sec¬ 
onds)  message  delivery’ .  This  approach  is  an 
effective,  expandable  wav  to  proceed  in  con¬ 
solidation  of  the  telecommur, ications  services 
<>n  i tabu. 


The  recommendations  cited  in  the  report 
are  currently  under  consideration  by  the  Joint 
Chiefs  of  Staff. 

ACCOUNTING  SYSTEM  STUDY 

A  short  study  was  conducted  to  examine 
the  accountability  of  use  of  the  ARP  A  com¬ 
munications  network  and  the  extended  net¬ 
work  of  ARPA  computing  facilities  coupled 
by  the  communications  network.  An  architec¬ 
ture  and  implementation  plan  for  network 
accounting  were  drafted  as  a  result  of  the 
examination.  The  study  was  initiated  because 
of  the  recognized  need  for  an  automated  ac¬ 
counting  system.  However,  discussions  during 
the  study  of  accounting  and  management 
needs  revealed  that  an  accounting  system  is 
only  the  kernel  of  a  broader,  partially -au  - 
tomated  ARPA  resource  management  system. 

Music.  Open-entlctl  System. 

A  basic  accounting  system  tha.  can  be 
made  operational  on  a  much  shorter  time 
scale  than  a  resource  management  system  is 
needed.  Thus,  the  substance  of  the  resulting 
report  is  a  model  for  an  accounting  tool  that 
stresses  reliability,  yet  is  open-ended  so  that 
it  may  evolve  into  a  resource  management 
system.  The  system  is  an  evolutionary  one 
because:  1)  consumers’  (i.e..  users  of  network 
resources)  desires  and  requirements  are  un¬ 
known;  2)  the  impact  of  future,  distributed 
operating  systems  oil  accounting  is  unknown: 
3)  radio  and  satellite  adjuncts  to  the  surface 
network  will  impact  accounting:  and  4)  the 
interconnection  of  networks  will  involve  ac¬ 
counting  practices. 

System  l  ses/ 1  sers 

The  accounting  system  involves  three  types 
of  participants:  ARPA,  who  provides  and 
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controls  budgets  to  accomplish  specific  re¬ 
search;  facility  managers,  who  provide  com¬ 
puting  services  to  support  the  contracted  re¬ 
search;  and  customers,  who  use  the  resources. 
Accounting  information  for  resource  utiliza¬ 
tion  may  vary  among  installations,  but  in 
each  case  should  be  simple  and  minimal  so  as 
to  aid  rather  than  obstruct  the  administrative 
effort. 

Resource  utilization  statistics  and  budget 
data  should  he  collected  and  stored  in  a 
highly  reliable  and  redundant  system,  This 
data  should  he  transmitted  over  the  network 
to  the  accounting  facility  and  maintained 
there  until  required  by  the  cost-  and  re¬ 
source  -leporting  system. 

System  outputs  are  designed  not  only  to 
report  use.  but  to  assist  the  customers,  the 
facility  managers,  and  ARPA  in  future  plan¬ 
ning  by  providing  timely  usage  reports  on  a 
level  of  detail  appropriate  to  the  recipient. 
With  regard  to  outputs,  the  system  has  built- 
in  guards  against  subordinate  compromise. 
System  .Architecture 

An  accounting  system  is  recommended  that 
is  partitioned  physically  and  logically  into 
two  kinds  of  subsystems  (see  Figure  5.1).  The 
first  subsystem,  the  data  collector,  is  dupli¬ 
cated  (one  on  each  Coast )  for  purposes  of 
reliability.  The  data  collectors  are  responsible 
for  the  fundamental,  invariant  properties  of 
accounting.  The  second  subsystem  (of  which 
there  is  only  one),  the  report  generator, 
evolves  according  to  the  changing  needs  of 
ARPA  resource  management. 

Thi!  data  collector  receives  as  input  new 
budget  information  from  ARPA,  suhalloc.it ion 
ol  budget  information  from  investigators,  and 
resource  usage  reports  from  facilities.  Ibis 


Figure  5.'.  Accounting  ci/oicn 
configuration. 


data  is  passed  on  demand  to  the  report  gener¬ 
ator,  with  the  latter  periodically  outputing 
reports;  the  generator  can  also  he  queried  in¬ 
teractively  over  the  network  to  produce  re¬ 
ports,  make  reservations  for  resource  use,  and 
supply  information  on  rates  and  services. 

Implementation 

The  report  discusses  reliability  and  security 
considerations  as  well  as  proposing  imple¬ 
mentation  milestones.  A  short  design  period 
was  recommended  in  order  to  specify  a  model 
system,  along  with  costs  and  an  implementa¬ 
tion  schedule.  Iteration  and  revision  should 
produce  a  final  system  specification.  A  pro¬ 
curement  and  implementation  phase  would 
then  result  in  a  testable  system.  This  would 
he  followed  by  a  checkout  phase  on  the  oper 
ational,  experimental  system 
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Further  Research 

The  study  was  reported  .  Jr.  Lawrence  G. 
Roberts.  ARPA  IPT,  who  discussed  the  need 
Tor  network  accounting  at  the  December  1972 
ARPA  Contractors'  meeting.  A  committee 
was  Formed  to  investigate  and  recommend 
accounting  policies. 

In  addition  to  this  effort,  the  Range  Mea¬ 
surements  Laboratory  (RML),  Patrick  Air 
Force  Base,  has  made  arrangements  with 
ARPA  to  assume  some  of  the  ARPANET 
management  functions.  The  RCA  Services 
Company,  who  provides  technical  assistance 
to  RML.  has  visited  ISI  to  discuss  the  study  as 
it  applies  to  their  interests  in  ARPANET 
management  functions. 

DA  TA  RECOXFIG  l  Ri  TI()\ 
SERVICE 

An  important  goal  of  ARPANET  work  is  to 
examine  the  fundamental  intercommunica¬ 
tions  problems  that  arise  in  resource  sharing 
among  dissimilar  systems.  The  Data  Recon¬ 
figuration  Service  (DRS)  [ 7.9.22)  is  a  network 
experiment  directed  toward  such  an  exami¬ 
nation.  The  experiment  involves  communica¬ 
tion  between  two  arbitrary  but  cooperating 
processes  with  different  input  /output  inter  - 
faces.  That  is.  the  DRS  acts  as  a  mediator, 
reformatting  data  passing  between  two  su¬ 
perficially  incompatible  processes,  to  allow 
them  to  converse  in  their  own  data  formats. 

Other  Approaches 

Three  approaches  to  solving  such  disparate 
<  ommumoations  requirements  are: 

t)  service  centers  (servers)  can  tailor  their 

software  interfaces  for  coupling  to  a  much 


2)  each  user  can  provide  the  necessary  soft¬ 
ware  interfaces  to  all  services  he  wishes  to 
access; 

3)  high-level  data -representation  protocols, 
to  which  both  users  and  servers  conform, 
can  be  defined. 

The  first  approach  is  highly  unattractive 
because  of  the  burdens  and  responsibilities  it 
places  on  service  centers.  The  second  is  like¬ 
wise  undesirable  because  it  implies  upgrading 
user  equipment  and  modifying  user  programs 
to  meet  service  center  specifications.  The  in¬ 
clination  to  date  has  been  toward  the  third 
approach.  Thus  far.  standards  have  been 
specified  for  logical  message -path  manage¬ 
ment,  teletype-like  character  transmission, 
and  file  transfer. 

DRS  Approach 

An  interim  (and  perhaps  even  long  term) 
solution  to  this  communications  dichotomy  is 
the  use  of  a  fourth  approach:  the  DRS.  The 
DRS  is  c  computer  program,  transparent  to 
both  user  and  server,  that  couples  user  and 
server  and  carries  out  transformations  on  data 
passing  between  them.  (See  Figure  5.2.) 

This  approach  offers  several  advantages. 
Because  the  reconfiguration  definitions  (called 


Figure  5.  2  Fat :  :*,  <>..  >  >. 

service  zekena:  ' j. 
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forms)  are  easily  specified,  user/server  inter¬ 
face  connections  can  be  readily  accomplished, 
with  only  minor  changes  made  to  their  re¬ 
spective  programs.  For  n  x  m  transforma¬ 
tions  (n  users  times  m  services),  there  need  be 
only  a  single  adaptable  transformer  in  the 
ARPANET. 

.in  Operational  DRS 

Six  ARPANET  sites  participated  in  the 
definition  of  a  DRS  language.  From  these 
specifications,  1S1  and  The  Rand  Corporation 
developed  a  DRS  compiler  \22\  and  the  Uni¬ 
versity  of  California  at  Santa  Rarhara  devel¬ 
oped  an  interpreter  and  a  network  runtime 
package  which  comhined  to  offer  a  real  time 
DRS  service  on  UCSB's  IBM  360/75.  The  com  - 
piler  takes  character  string  definitions  of  data 
transformations  and  produces  an  intermediate 
(compiled)  representation  of  the  definition. 
The  interpreter  applies  the  compiled  defini¬ 
tions  to  data  streams  passing  hetween  user 
and  server  in  real  time. 

The  service  is  now  operational  at  UCSB  on 
an  experimental  basis  and  has  been  used  by 
iSI  and  UCSB.  Other  planned  uses  will  he 
reported  via  the  Stanford  Research  Institute, 
Network  Information  Center,  Request  for 
Comments  mechanism. 

Research  Trends 

Results  of  the  DRS  experiment  are  incon¬ 
clusive  at  this  moment  because  the  service 
has  been  operational  only  a  short  time.  How¬ 
ever,  several  observations  carl  be  made.  The 
overhead  in  CPU  costs  for  the  software  ver¬ 
sion  of  DRS  would  probably  prohibit  its  use 
for  large  volume  data -handling  applications. 
As  a  computer  program,  the  DRS  can  be  most 
effective  in  operating  a  one-time-only  data 
reformatting  service,  where  the  original  data 


is  in  one  or  more  formats  and  where  writing 
programs  to  reformat  the  data  would  lx?  time 
consuming.  From  the  standpoint  of  economics, 
a  version  of  the  DRS  could  be  implemented  in 
hardware  if  sufficient  use  at  UCSB  warrants. 

PORTABLE  TERMINALS 

Development  of  a  portable  terminal  for  use 
with  the  ARPANET  is  in  progress.  The  ter¬ 
minal  will  provide  travelers  with  a  device 
ahle  to  communicate  from  any  telephone  to 
any  ARPANET  site.  That  is.  mohile  users  can 
send  and  receive  mail  and  messages,  as  well 
as  using  other  ARPANET  services. 

Size  mill  II  Wg/n. 

The  terminal  will  be  housed  in  a  small 
briefcase  (approximately  10”  x  14”  x  6”)  for 
portability,  and  will  weigh  about  20  pounds. 
In  contrast,  conventional,  complete  portable 
display  terminals  are  hulky.  hard  to  carry, 
and  weigh  about  35  pounds.  Off-the-shelf 
components  are  heing  used  in  the  packaging 
effort  to  facilitate  prototype  development  and 
evaluation. 

Sin  nil  aril  llnnilsel. 

The  terminal  will  connect  to  any  standard 
telephone  handset  and,  via  the  telephone  line, 
to  any  300  baud  Bell  102  compatible,  full- 
duplex.  acoustic  coupler  dial-up  unit.  There 
will  be  an  RS-232  EIA  interfate  for  fast,  local, 
direct  access. 

Ki'vlnmnl  anil  IHs/tlm, . 

The  terminal  uses  an  electronic  I  lull -effect 
53  key  keyboard  with  a  Model  33  character 
set  and  a  Burroughs  sell -scan  panel  display 
unit  with  6  lines  of  32  characters  (250  charac¬ 
ter  display).  The  display  i;  alphanumeric,  up¬ 
per  case.  only.  The  terminal  transmits  and 
receives  the  entire  US  ASCI  I  character  set. 
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Second  Generation  Portables 

The  completion  date  for  the  prototype  is 
July  1,  1973.  In  a  longer  range  effort,  several 
alternative  display  devices  are  being  evalu¬ 
ated.  I'he  ultimate  goal  is  to  produce  a  2,000 
character  display  terminal  having  the  same 
capabilities  and  portability  of  the  model  de¬ 
scribed  above.  An  80  character  per  line.  25-30 
line  display  is  desired  with  an  active  viewing 
area  of  about  40  square  inches  (8”  x  5”).  The 
Owens-Illinois  plasma  panel  and  the  conven¬ 
tional  CRT  can  feasibly  satisfy  this  require¬ 
ment:  no  other  devices  have  the  required  res¬ 
olution  (dot  spacing  of  about  .015”).  Because  of 
the  advaniages  of  gas  panels  (relative  shock 
and  vibration  immunity,  higher  contrast 
(80:1),  etc.)  over  CRTs,  the  gas  panel  displays 
will  be  carefully  evaluated  for  the  second 
generation  portable  terminal. 

The  completion  of  the  second  generation 
terminal  depends  on  the  availability  of  a  suit¬ 
able  display  device:  delivery  could  he  as  early 
as  several  months  or  as  long  as  a  year.  Efforts 
will  continue  in  encouraging  development  of 
this  iype  of  display  to  fill  the  need  for  such  a 
portable  terminal.  Means  are  also  being 
sought  to  significantly  reduce  the  weight  and 
size  of  the  unit.  The  curtent  effort  with  the 
258  character  terminal  will  produce  an  evalu¬ 
ation  instrument  that  will  aid  in  defining  the 
minimum  terminal. 
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INTRODUCTION' 

The  goals  of  this  project  during  the  past 
twelve  months  have  been  to:  1)  evaluate  the 
technological  feasibility  of  significant  ad¬ 
vancements  in  computer-based  manufactur¬ 
ing  systems  for  discrete  product  manufacture: 
2)  evaluate  the  economic  impact  on  1X>1)  and 
the  U.S.  economy  derived  from  implementa¬ 
tion  of  those  advancements:  and  3)  define  the 
development  program  required  to  achieve 
those  advancements,  including  areas  to  be 
addressed  and  resources  required.  Those  goals 
have  been  achieved.  The  evaluations  and  rec¬ 
ommendations  have  been  given  to  ARPA  in  a 
final  report  on  the:  study  phase  of  this  project 

I 'I 

A  major  economic  analysis  has  been  per 
formed  of  the  cost.  lal>or,  and  industry -struc- 
nire  factors  characterizing  1)01)  procurement: 
in  addition,  several  detailed  ease  analyses 
have  been  made  of  particular  1)01) -related 
manufacturing  operations  in  order  to  under¬ 
stand  the  manufacturing  enterprise  as  a  sys¬ 
tem. 

'1  he  Department  of  Delense  procures  over 
$20  billion  worth  of  discrete  goods  each  year: 
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the  great  majority  of  these  goods  are  sophisti¬ 
cated.  precision  products  --  often  electronic- 
based  --  procured  in  rather  small  quantities. 
They  are  predominantly  batch -produced.  It  is 
precisely  in  this  category  of  discrete  manu¬ 
factured  products  that:  1)  the  U.S.  has  a  com¬ 
parative  advantage  in  world  markets:  and  2) 
IX)1)  requires  healthy,  efficient,  national  man¬ 
ufacturing  support. 

Hatch  manufacture  of  discrete  precision 
products  is  characterized  by  a  dynamic  envi¬ 
ronment  with  continually  changing  priorities 
and  job  mix.  Computers  are  not  now  being 
used  effectively  in  this  type  of  manufacturing 
environment  to  provide  accurate  up-to-date 
status  information  for  management  and  for 
allocation,  control,  and  monitoring  of  produc¬ 
tion  resources.  This  is  due  to  the  inflexibility 
of  existing  software,  the  lack  of  interlaces 
natural  to  managers  in  this  environment,  and 
insufficient  real  time  status  reporting  from  the 
production  processes. 

A  wide  range  of  potential  computer  based 
manufacturing  systems  have  been  examined 
which  might  increase  manufacturing  produc 
livitv.  ranging  from  near  total  programmable 
automation  of  manufacturing  including 
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assembly  and  inspection  processes  --  to  in¬ 
cremental  enhancements  to  existing  systems. 
The  conclusion  has  berm  made  that  the  most 
important  development  required  by  ITS.  in¬ 
dustry.  and  by  DOD  related  industries  in 
particular,  is  flexible,  real  time  software  sys¬ 
tems  that  can  be  used  dircedv  by  a  manager 
and  modified  by  him.  As  a  consequence.  these 
systems  must  have  some  limited  modeling, 
deductive,  decision-making,  and  specialized 
language-understanding  capabilities.  The  de¬ 
velopment  of  a  demonstration  system  hav  ing 
these  features  is  recommended:  components  of 
such  a  system  can  be  a  distributed  resource, 
shared  among  several  users  and  accessed  by 
them  on  a  demand  basis.  Effective  control 
software  for  complex  batch  production  env  i¬ 
ronments  is  a  necessary  precursor  to  efficient 
use  of  other  advanced  automation  technolo¬ 
gies,  such  as  automated  assembly  and  ins|)ec- 
tion  systems,  The  primary  direct  benefits  ol 
an  effective  batch  production  management 
system  are:  1)  reduced  inventory  costs:  2) 
greater  productivity  through  higher  utiliza¬ 
tion  of  resources;  and  d)  better  ability  to  meet 
schedules  resulting  in  less  slippage,  defaults, 
and  cost  overruns.  Due  to  the  high  degree  ol 
concentration  of  1)01)  procurement  in  a  few 
major  industries,  advanced  computer  based 
manufacturing  systems  introduced  into  these 
key  industries  can  have  a  major  impact  in  a 
relatively  short  time. 

it  is  recommended  that  research  also  be 
continued  in  computer -controlled  manipula¬ 
tion  ill  objects,  with  particular  emphasis  on 
the  mechanical  dexterity  required  m  assem¬ 
bly  ol  avionic  packages  and  oilie;  electronic 
based  units.  Assembly  and  testing  operations 
of  this  scale  will  not  be  eliminated  by  the 


continuing  revolution  in  elect  ninit  compo¬ 
nents.  and  will  Ih*  of  increasing  importance  in 
hatch-made  products  procured  by  1)()D. 

The  batch  production  manufacturing  envi¬ 
ronment  requires  a  sophistication  in  com¬ 
puter-based  resource  control  systems  which  is 
not  available  commercially,  but  elements  of 
which  have  been  demonstrated  in  research 
laboratories,  particularly  within  the  ARPA 
contractor  community.  Those  research  capa¬ 
bilities  must  now  lx:  transferred  to  practical, 
commercial  use. 

IMPORT  iXT  CHARACTERISTICS 
OF  HOI)  PROCA  REMEST 

The  characteristics  of  both  the  manufac¬ 
tured  goods  bought  by  1)01)  and  the  indus¬ 
tries  supplying  those  goods  differ  markedly 
from  the  characteristics  of  the  goods  and  in¬ 
dustries  in  the  rest  of  the  ITS.  economy.  The 
following  issues  summarize  the  results  pre¬ 
sented  in  reference  |1|:  these  issues  must  he 
considered  in  formulating  an  R&l)  program 
which  will  have  a  major  impact  on  the  pro¬ 
ductivity  of  DOD  suppliers. 

Issue  1:  Thu  purchasing  power  i>!  / toil's  pm 
curcmriil  lii/dgcl  Is  declining. 

The  budget  of  the  Department  ol  Defense 
can  be  considered  as  comprising  two  major 
components:  discretionary  funds  (such  as  pm 
cinement’.  over  which  DOD  has  yearly  bud 
gutary  control):  and  nundiscret ionary  funds 
(such  as  personnel  salaries,  over  vvhii  h  there 
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is  little  immediate  control).  Figure  6.1  shuws 
the  breakdown  of  LX)D's  budget  for  FY  1972 
into  these  categories  and  their  major  subcom- 
[Kinents. 

During  the  past  ten  years,  the  portion  of 
1 XII j  s  budget  allocated  to  procurement  has 
declined: 

1)  as  a  percentage  of  the  DOD  budget 
(down  10".): 

2)  as  a  percentage  of  the  Federal  budget 
(down  7.4'!.’.): 

3)  as  a  percentage  of  the  GXP  (down  1.3%). 

It  inflationary  effects  are  considered,  the  real 
purchasing  power  of  DOD's  procurement 
budget  during  the  last  decade  has  declined  26 
percent. 

•  Conclusion  1:  It  is  vital  that  DOD  obtain 
more  value  per  procurement  dollar. 


Figure  6.1  DOD  budget  FY1972.  lotal 
DOD  budget ,  FY1972  ~  $76.  7  billion. 
Source:  The  Budget  of  the  U.S.  Govern¬ 
ment ,  FY1972. 


Issue  2:  IX)L)  procurement  is  characterized  by 
relatively  small  quantities  of  sophisticated  items, 
munufuctured  primarily  by  hatch  production 
methods. 

Figure  6.2  shows  a  breakdown  of  DOD  pro¬ 
curement  by  number  of  major  end -items  pur¬ 
chased.  This  chart  was  derived  from  the  Pro¬ 
curement  Annex  of  the  Five-Year  Defense 
Plan.  On  one  hand,  it  understates  actual  pro¬ 
duction  quantities  of  subcomponents,  since 
tnere  is  some  dunlication  of  parts:  on  the 
other  hand,  the  pnxuirement  budget  does  not 
take  into  account  the  significant  DOD  ex¬ 
penditures  for  research,  development,  test,  and 
evaluation  (R.D.T&E)  in  which  large  sums  are 
spent  on  the  construction,  in  very  small  quan¬ 
tities,  of  prototypes. 


NUMBER  OF  END-ITEMS  PURCHASED 

Figure  6. 2  DOD  procurement  by  number 
of  major  end-items  purchased.  Source: 
Procurement  Annex,  Five-Year  Defense 
Program  ( FYDP ) . 
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The  low  production  quantities  shown  by 
Figure  6.2  dictate  that  batch  production  meAi 
ods  be  used  by  most  major  DOD  suppliers  and 
their  subcontractors.  (See  [2j  for  a  discussion 
of  the  distinction  among  batch  production, 
mass  production,  and  process  control  manu¬ 
facturing  methods.) 

•  Conclusion  2:  Developmental  programs 
aimed  at  increasing  the  productivity  of  DOD 
suppliers  should  concentrate  on  the  batch 
production  manufacti  ring  environment. 

It  should  be  noted  that  the  prime  example 
of  past  DOD  sponsorship  of  manufacturing 
technology,  namely  numerically -controlled 
machine  tools  [:t|  was  aimed  explicitly  at 
batch  production  techniques. 

Issue  DOD  procurement  is  heavily  enneen  • 
Irulcd  in  u  few  mujor  industry  categories. 

Table  6.1  summarizes  major  DOD  procure¬ 
ments  by  program.  Aircraft  and  missiles  alone 
account  for  over  50  percent  of  DOD  procure¬ 
ment;  with  ships,  they  account  for  over  75 
percent  of  procurement. 

•  Conclusion  3:  Proposed  defense  productiv¬ 
ity  enhancement  techniques  should  directly 
address  problems  in  the  aerospace!  industries 
and  their  suppliers,  with  a  product  mix  char¬ 
acterized  by:  1)  precise,  high  performance, 
costly  materials  and  assembly  processes,  and 
2)  electronic -based  subsystems. 

Issue  - 1  1)01)  jirnrureme;il  is  lieuvily  dinninuled 
hy  a  few  eoi  porolinns. 

Table  6.2  shows  the  top  ten  contractors  for 
FY  1672.  The  prime  contracts  which  they 
control  account  for  35.1  percent  of  all  DOD 
procurement.  The  top  100  contractors  have 
prime  contracts  accounting  for  72.1  percent  of 


DOD  procurement,  and  the  amount  of  con¬ 
tract  award  concentration  in  the  top  100  con¬ 
tractors  is  increasing. 

•  Conclusion  4:  1)  It  is  possible  for  DOD  to 
have  a  substantial  amount  of  contractual 
leverage  in  promoting  t hi?  adoption  of  new 
manufacturing  techniques;  and  2)  any  pro¬ 
posed  productivity -enhancement  program 
should  directly  address  the  needs  oT  these 
important  suppliers  and  their  subcontractors. 

Again,  the  history  of  the  transfer  of  numer¬ 
ical  control  technology  [3]  into  industry  em¬ 
phasizes  the.  unique  role  DOD  can  play  in 
sponsoring  nev\  manufacturing  technologies, 
due  to  the  concentrated  control  it  has  over  its 
suppliers. 

Issue  5:  The  industry  cast  and  labor  structure  for 
mujor  DOD  suppliers  is  signi'ficunlly  different  from 
other  industry  categories. 

Table  6.3  compares  the  labor  breakdown  in 
the  aircraft  and  missile  industry,  and  the 
electronic  equipment  industry  (both  impor¬ 
tant  DOD  suppliers),  with  automobile!  manu¬ 
facturers.  It  shows  that  the  ratio  of  adminis¬ 
trative.  clerical  and  sales*  employees  per  pro¬ 
duction  worker  is  three  limes  more  for  air¬ 
craft  and  missile  manufacturers  than  for  au¬ 
tomobile  manufacturers. 

There  are  certainly  many  complex  reasons 
for  the  variance  in  labor  breakdown  between 
Ihi!  aerospace  and  automotive  industries:  the 
unique  reporting  and  documentation  require¬ 
ments  of  government  contractors;  greater  lest  - 
mg  and  inspection  requirements  in  aerospace 


’“AilininistMhvr.  (  Utic.iI,  .jd«1  x.ilrx"  is  .1  I  S  I irp.i? imrnt  i»! 
(.nmmtite  trim  ntt  ninp.issm^  nMii.i^rrs.  .11 1  uur,!..n!s.  Idw  ycrs. 
Iliir.il  Mils,  nlitius.  1  mi  I  r  li.tsmy:  .iigruts.  honk  krr'M  1  x.  rxtim.ltnss 
iittur  m.uhir.  ujMM.ihirv  xcMrUtirs,  shipping  .uni  in  n\  mt; 
c  Ifi  kx.  -.ti *»  k  i  in  ks.  ,m<i  xjihii.u  I  mu  I  inns 
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Table  6.1 

SUMMARY  OF  DOD  MAJOR  PROCUREMENT  PROGRAMS 

1971-1973 


Program 

1971 

% 

1972e 

% 

1973e 

_% 

Aircraft 

6.3 

35 

6.6 

35 

5.9 

31 

Missiles 

3.3 

19 

3.4 

18 

3.7 

19 

Ships 

2.3 

13 

3.0 

16 

3.6 

19 

Other 

5.9 

33 

5.9 

31 

6.1 

32 

Total 

17.8 

100 

18.9 

100 

19.3 

100 

e  =  estimated  (in  $  billion) 

Source:  The  budget  of  the  United  States,  1973  Appendix,  p.  296. 


work;  batch  production  versus  mass  produc¬ 
tion  manufacturing  methods.  The  point  is  not 
that  one  industry  is  better  or  worse  than 
another,  but  that  there  are  basic  differences 
which  should  be  taken  into  consideration. 

•  Conclusion  5:  1)  The  unique  characteristics 
of  DOD  suppliers  require  a  productivity -ori - 
ented  development  program  tailored  to  their 
needs;  and  2)  two  major  high -cost  areas 
which  should  be  explicitly  considered  are: 

a)  administrative,  clerical,  and  sales  func¬ 
tions  in  the  aircraft  industries  (one -quarter 
of  all  industry -related  lalwr);  and 

b)  assembly  in  the  electronic  component 
and  subsystem  manufacturing  industries 
(42  percent  of  all  industry -related  labor). 


Issue  (>:  DOD-rclatc<l  industries  hold  rolativcly 
(urge  and  expensive  inventories. 

The  value  of  inventories  for  all  manufac¬ 
turing  groups  at  the  end  of  1967  amounted  to 
$84.4  billion.  The  major  DOD -related  indus¬ 
tries  (e.g.,  aircraft  and  parts,  ships,  and  com¬ 
munications  equipment)  are  among  those 
with  exceptionally  high  inventory  costs,  most 
of  which  are“work  in  process”and“materials”; 
the  latter  are  in  contrast  to  “finished  goods” 
subject  to  external  demand  factors. 

On  the  average,  U.S.  manufacturing  indus¬ 
try  holds  about  15  percent  of  the  value  of 
shipments  in  inventory  on  hand;  however,  the 
following  are  representative  ratios  of  inven¬ 
tory/shipments  for  DOI) -related  industries: 


71 


PROGRAMMED  AUTOMATION 


Communications  Equipment 

24% 

Aircraft  and  Parts 

35% 

Shipbuilding 

30% 

The  approximate  cost  to  LX)D  per  year  for 
inventories  on  hand  for  IX)D-related  manu¬ 
facturing  is  in  excess  of  $1  billion. 

•  Conclusion  (i:  A  reduction  of  in  -  process 
inventories  in  DOD-related  industries  can 
substantially  reduce  procurement  costs. 

CASE  STUDIES  OF  KEY 
M  i  M  FA  CTl  RING  INDUSTRIES 

During  the  past  twelve  months,  members  of 
this  project  have  met  with  over  forty  repre¬ 
sentatives  of  industry,  research  groups,  and 
the  government,  and  have  inspected  over 
thirteen  different  manufacturing  facilities 
throughout  the  U.S.,  covering  a  wide  range  of 
products  and  technologies.  The  following 
three  facilities  represent  many  of  the  varied 
job  shop  environments  of  importance  in  the 
manufacture  of  1X)D  products.  Detailed  case 
studies  of  these  three  manufacturing  environ¬ 
ments  have  been  made,  with  the  active  coop  - 
oration  of  the  line  managers  responsible  for 
production.  The  facilities  studied  are: 

1)  TOW  Missile  Production,  Tucson  Divi¬ 
sion,  Hughes  Aircraft  Oompany,  Tucson, 
Arizona: 

2)  Manufacturing  Department,  Precision 
Products  Division,  Western  Clear  Corpora 
tion,  Lynwood,  California: 

3)  Numerical  Control  Fabrication  Facility, 
Douglas  Aircraft  Company,  Torrance.  Cali¬ 
fornia. 


In  each  study,  a  variety  of  possible  com¬ 
puter-based  system  innovations  was  exam¬ 
ined  which  might  have  a  significant  impact 
on  productivity,  from  near -total  programma¬ 
ble  automation  of  the  manufacturing  process 
to  incremental  enhancements  of  existing  ma¬ 
chines  or  control  processes.  Each  of  these  case 
studies  is  summarized  lielow,  together  with 
conclusions  about  the  potential  impact  of  ad¬ 
vanced.  computer-hased  manufacturing  sys¬ 
tems  on  the  production  of  these  products. 

TOW  Missile  Production,  Tucson 
Division,  Hughes  Aircraft  Company 

Due  to  the  widespread  use  of  electronics 
packages  in  products  procured  hy  DOD,  it  was 
felt  important  to  study  the  manufacture  of  a 
product  having  an  electronic  module.  After 
examining  several  possihle  candidates,  the 
Army’s  TOW  (Tube -launched,  Optically  - 
iracked.  Wire-guided  missile),  manufactured 
by  the  Tucson  Division  of  Hughes  Aircraft 
Company,  was  picked  as  being  representative 
of  a  large  class  of  elect  runic -based  military 
products.  Figure  6.3  shows  the  various  com¬ 
ponents  of  the  TOW  missile. 

Some  relevant  data  concerning  TOW  pro¬ 
curement: 

1)  Procured  materials  and  subassemblies 
account  for  about  70  percent  of  the  TOW 
factory  cost;  therefore,  automation  technolo¬ 
gies  introduced  only  at  the  Tucson  plant 
could  affect  at  most  30  percent  of  the  cos!.* 

2)  Engineering  changes  are  a  significant 
item.  During  the  production  engineering 
phase  (1000  1000),  about  24  engineering 

*Onr  might  * •  x | h *< »  st^rufn  ,uil  i.h.mges  id  nuke  utsiis  imy 
tlti.tsiims  if  high  ilruriv  i»l  inmputri  h.isi'ti  .mtum.ih'.in  urn* 
i ill r<H f i it I  However  in.nn  tin  tsiimr.  !«•  hn\*  triim  suppliers  «i re 
iTi.iile  on  the  hosts  ut  llii  ilesigu  i  mu peti  nrr  til  those  suppliers 
{fur  mu  It  i  nm|mnei»ls  <t  gyros.  Uillei  ot  tuotinn  s\  sinus) 
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Table  6.2 

THE  TOP  TEN  DOD  CONTRACTORS  FOR  FY  1972 
(IN  DOLLAR  VOLUME  OF  PRIME  CONTRACTS) 


Company 

DOD 

Contracts* 

%  of 
Total 

1 

Lockheed 

1.7 

5.1 

2) 

McDonnell  Douglas 

1.7 

5.1 

3) 

General  Dynamics 

1.3 

3.9 

4) 

General  Electric 

1.2 

3.7 

5) 

Boeing 

1.2 

3.5 

6) 

American  Telephone 

1.1 

3.4 

7) 

Grumman  Corporation 

1.1 

3.4 

8) 

United  Aircraft 

0.9 

2.9 

9) 

North  American  Rockwell 

0.7 

2.1 

10) 

Hughes  Aircraft 

0.7 

2.0 

Total 

11.6 

35.1% 

*(in  $  billion).  These  figures  are  rounded. 

Source:  "100  Companies  Receiving  the  Largest  Dollar  Volume  of 
Prime  Contract  Awards",  DOD  (OASD)  Directorate  for 
Information  Operations. 


73 


PROGRAMMED  AUTOMATION 


Table  6.3 

COMPARATIVE  LABOR  BREAKDOWNS  IN  THE  AUTOMOTIVE, 


AEROSPACE, 

Non-production 

employees 

-  R&D  and  other 
technical 

-  Admin.,  clerical 
sales 

Totals 

AND  ELECTRONIC  INDUSTRIES  (1970) 

%  Radio  &  TV 

%  Motor  %  Communications 

Vehicles  Aircraft  Equipment 

&  Parts  &  Parts  &  Electronics 

7 

/ 

12 

19% 

19 

25 

44% 

18 

21 

39% 

Production  employees 

-  Machining 

11 

16 

3 

-  Assembly 

30 

9 

42 

-  All  other 

40 

31 

J6_ 

Totals 

81% 

56% 

61% 

a)  Total  employment  in 

720,200 

644,900 

990,200 

listed  industry 

b)  Total  employment 

1,793,300  1 

,102,800  1 

,683,300 

created  in  all 

industries* 

Ratio  of  b)  to  a) 

2.5 

1.7 

1.7 

*Toto!  employment  created  in  all  industries  is  estimated  using 
productivity  changes  and  input-output  data  on  interindustry  transactions. 


Source:  Census  of  Manufacturers,  U.S.  Department  of  Commerce. 
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change  analyses  were  made  each  month.  Each 
analysis  defines  a  real  problem  and  its  engi¬ 
neering  solution  and  cost.  It  may  affec'  sev¬ 
eral  different  production  drawings,  fly  the  end 
of  1971,  aiter  about  eighteen  months  of  nor¬ 
ma!  production,  there  were  still  about  fifteen 
analyses/month  performed,  and  these  re¬ 
sulted  in  about  eignt  formal  engineering 
change  proposals  per  month,  all  requiring  the 
approva1  of  the  Army  Contracting  Officer, 
because  the  change  would  affect  the  form,  fit, 
function,  or  contract  price  of  the  product. 

3)  The  overhead  rate  is  about  130  percent. 
The  cost  to  the  government  is  about  $12.50/ 
hour  (including  G&A)  per  person  on  a  pro¬ 
gram  such  as  TOW.  There  are  currently  about 
400  people  at  Tucson  on  the  TOW  program 
(including  supervisors  and  other  support  per¬ 
sonnel). 

4)  Rework  costs  can  he  significant.  The 
most  common  cause  is  failure  of  electronic 
components,  especially  during  vibration  tests. 
The  failure  rate  of  the  TOW  electronic  pack¬ 
age  during  production  is  hetween  3  and  10 
percent.  (Only  packages  which  eventually 
pass  all  such  tests,  of  course,  are  assembled 
into  the  missile.  After  passing  all  such  tests, 
the  reliability  of  the  TOW  end  product  has 
been  notable.)  On  a  much  more  sophisticated 
missile  such  as  Phoenix,  about  30  percent  of 
the  labor  is  involved  in  rework  during  early 
production  phases. 

5)  In  October  1971.  at  a  production  rate  of 
about  (iOO/munlh.  the  unit  price  of  a  TOW 
missile  was  above  $3,500  This  was  on  a  onc- 
year  contract.  Currently,  Hughes  has  a  four 
year  guaranteed  procurement  contract.  At  the 
current  production  rate  of  1500/monlh,  the 
average  unit  price  (including  O&A  and  profit) 


is  about  $2,200.  A  major  source  of  these  sav¬ 
ings  has  been  significantly  lower  negotiated 
prices  from  suppliers,  due  to  the  four-year 
procurement  potential. 

Based  on  analysis  of  TOW  and  other  elec¬ 
tronic-based  1)01)  procurement  items,  the  fol¬ 
lowing  general  observations  have  lx;en  made: 

1)  The  continuing  revolution  in  electronics 
(LSI,  thin  films,  electron -beam  etching,  etc.) 
will  not  eliminate  the  assembly  task  in  elec¬ 
tronic  packages.  DOD's  appetite  for  electronics 
seems  to  be  constant  volume,  not  constant 
function.  When  the  space  behind  the  warhead 
of  a  missile  can  hold  an  array  computer,  it 
probably  will.  The  fact  that  a  single  chip  will 
perform  the  functions  of  an  entire  circuit 
board  will  only  lead  to  more  complex  designs 
involving  many  such  chips  The  space  is 
there,  and  the  increased  functions  can  usually 
he  justified. 

2)  The  electronics  revolution  does  not  have 
a  rapid  effect  on  the  production  of  military 
weapons  systems.  The  design  of  the  TOW,  for 
example,  was  basically  frozen  in  19(15  when 
the  first  prototype  flew.  Successful  designs, 
having  undergone  elaborate  testing  and  vali¬ 
dation,  are  not  usually  changed  in  such  fun¬ 
damental  way:-,  as  revamping  the  electronics 
based  on  next -generation  possibilities.  The 
hybrid  circuit  boards  in  the  TOW  will  lie 
around  in  it  and  in  similar  products  for  many 
more  years. 

3)  Many  of  the  suhassembh  tasks  involved 
in  the  electronic  and  light  source  units  seem 
potentially  automatable,  and  they  seem  to 
absorb  a  disproportionate  amount  of  assembly 
labor  at  present  (about  one  third  of  total  as¬ 
sembly  labor).  I’he  assembly  operations  re 
quired  for  such  subassemblies  are  the  most 
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prom  sing  yet  seen  lor  the  potential  appliea 
lion  ol  programmable  assembly  nun  liino 
techniques 

ManuftH'lurlnii  Department.  Precision 
Products  Dirision.  II  cslcru  dear 
Corporal  ion 

Western  C.e;ir  ( impend ion  is  the  largest 
independent  manuluclurer  on  the  West  (  oast 
ol  such  precision  mechanical  prudm  is  .is 
goarlxixes  <md  .ictn.itors.  Almost  every  I  )<  >! ) 
prime  contractor  manufacturing  aircr.ilt. 
ships,  nr  missiles  siibcont rai.ts  to  Western 
dear. 

The  Precision  Products  Division  at  Tor 
ranee,  dalilornia  is  an  excellent  example  ol  a 
job  shop;  at  any  spccilie  time,  about  Tout) 
diverse  Manulucltu  ing  Orders  are  in  process. 
The  case  study  Focused  on  two  aspects  ol 
manulacturing  at  Western  dear:  1)  the  de 
tailed  processes  involved  in  their  maimlaitiire 
of  one  specific  gearbox;  and  2)  the  system  by 


which  .1  manager  allot  ates  and  controls  man- 
id  ii  tunny;  rcsoim  es  and  jobs  in  this  complex 
job  shop  environment.  1'lie  gearbox  analyzed 
is  shown  in  Figure  ti  t.  him  ol  them  are  used 
by  I .oi  F heed  in  each  ( .  1  lit!  aircral I. 

I’.ac!.  box  contains  the  Following  twelve 
m.i|or  components.  each  ol  which  is  Fabricated 
by  Western  de.n  tmm  materials  purchased 
i  mtside: 

ol  AVI'ITV  PA  IT  I  l)i:S(  iRIPTK  )\ 

i  Housing  Mam 

1  (.over  Housing 

1  Retainer  Hearing 

i  Shalt  Input 

^  Liner  Hearing 

t  Sleeve  Hearing 

i  ( lear  Hovel 

1  Adapter  Hearing 

I  dear  Output 

t  ( .ear  Intermediate  Spur 

1  Spacer  Hearing 


Figure  6.4  Gearbox  manufactured  by  Western  Guar  Gorporation 
for  Lockheed  C-130  aircraft.. 
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For  the  fabrication  of  these  twelve  parts,  and 
the  assembly  and  test  of  the  gearbox,  about  26 
man-hours  of  direct  labor  are  required,  about 
75  percent  of  which  are  involved  in  direct 
operations  and  25  percent  in  setup.  The  per¬ 
centage  breakdown  of  direct  operation  labor 
cost  by  department  is  shown  in  Table  6.4, 

The  percentage  breakdown  of  setup  labor  cost 
by  department  is: 


DEPARTMENT 

Heat  treat 

Plating 

Sawing 

Turning!  rough) 
Total  Other* 


OF  TOTAL  DIRECT 
SETUP  LABOR 


'(lusting  stores  grinding  (2" .):  stores  12”,).  N  C  murluning 
(1.!)".):  turning  line  ( 1  7” small  gear  cutting  ( 1  *»•'..);  large 
tievel  gear  cutting  (0.7"  );  inspection  (O.ti  );  spindle  drilling 
(().:»■: .);  milling  |o,2' 


Perhaps  the  most  significant  statistic  con¬ 
cerning  the  production  of  this  simple  gearbox 
is  that  258  movements  of  ports  (x.-lween  different 
toco  (ions  ore  required.  Clearly,  in  a  job  shop 
environment  the  control  of  in-process  parts, 
tooling,  and  materials  is  a  major  considera¬ 
tion. 

All  of  the  departments  involved  in  the 
above  manufacturing  steps  were  inspected 
and  the  operations  were  discussed  with  the 
Manufacturing  Manager.  The  following  are 
some  of  the  major  observations  and  the  con¬ 
clusions  drawn: 

1)  The  operation  in  which  this  gearbox  was 
least  representative  of  average  products  at 
Western  Gear  was  final  assembly.  Most  gear¬ 
boxes  contain  five  or  ten  times  as  many  parts, 
which  increases  the  demands  on  the  assem¬ 
bler  for  dexterity,  precision,  and  judgment.  He 
is  called  on  to  use  additional  skills,  not  the 
same  skills  more  often. 

2)  There  are  so  many  inadequately  control¬ 
led  variables  in  the  physical  properties  and 


Table  6.4 

DIRECT  OPERATIONS  LABOR  BREAKDOWN, 
C-130  GEARBOX 


Department 

%  of  Total  Direct 

^  of  Distinct 

Involved 

Operation  Labor 

Operations 

Inspection 

19 

50 

Small  gear  cutting 

15 

10 

Grinding 

14 

44 

Turning  (rough) 

13 

19 

(De)burring 

10 

17 

N/C  machining 

7 

9 

Large  bevel  gear  cutting 

5.7 

5 

Heat  treating 

5.5 

35 

Assembly 

4.6 

4 

Turning  (fine) 

4 

11 

Spindle  drilling 

1 

4 

Sawing 

1 

8 

Milling 

0.2 

1 

Totals 

100.0% 
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processing  of  metals  that  feu  geurlioxes 
would  meet  the  stringent  1)01)  specifications 
without  the  continuous  use  of  ingenuity  by 
operators  to  beat  the  odds.  Whim  part  fabri¬ 
cation  operations  have  been  automated  (eg., 
with  numerically -controlled  machine  tools), 
the  cost  of  the  machines  easily  justifies  the 
relatively  small  additional  expense  of  a  hu 
man  operator  to  monitor  the  machine's  ))er- 
formance:  his  reaction  to  malfunctions  de¬ 
tected  by  subtle  patterns  of  sight,  sound, 
smell,  and  touch  sensations  can  save  tens  of 
thousands  of  dollars  and  weeks  of  downtime. 

•  Conclusion:  Significant  reductions  in  direct 
labor  are  not  possible  (for  this  and  similar 
precise  mechanical  products  manufactured  to 
existing  1)01)  specifications).  The  only  hope 
for  cost  reduction  through  automation  of  ex¬ 
isting  manual  operations  for  these  products 
would  seem  to  be  a  radically  new  design 
philosophy  allowing  very  reliable,  accurate 
products  (such  as  airplanes  and  missiles)  to  be 
made  from  components  whose  specifications 
have  considerable  latitude:  such  a  develop¬ 
ment  is  highly  unlikely 

8)  An  operator  can  usually  meet  or  exceed 
the  time  standards  for  the  set  up  and  per¬ 
formance  of  each  process  il  the  material,  tools, 
mlonnation.  equipment,  and  conditions  are  on 
time  and  correct.  It  is  not  now  possible  for 
management  to  control  all  these  iactors  and 
meet  those  criteria  :n  at  least  half  the  cases: 
nearly  all  significant  deviations  Iroin  lime 
standards  can  lie  traced  to  these  causes 

•  ( .occlusion:  The  management  and  control 
ol  nsonries  in  a  job  shop  environment  is 
currently  a  major  source  ol  inefficiency.  The 
investigation  ol  computer  base  1  production 
control  systems  to  aid  m  the  management  ol 


these  resources  in  a  job  shop  environment 
must  have  high  priority. 

4)  During  January  1973.  at  the  time  this 
study  was  performed,  the  Manufacturing  De¬ 
partment  had  about  a()0  employees,  and 
monthly  hillings  were  a  I  m  i  • :  t  $2.0(K).(.KXJ.  The 
overhead  rate  charged  was  180  percent;  of 
this,  about  80  percent  represented  rent  and 
other  occupancy  factors,  fringe  benefits,  and 
equipment  depreciation.  The  remaining  100 
percent  represented  management  and  support 
services,  i.e..  people.  For  each  man  performing  u 
(linn  I  upnrahan  ilium  ivus  woodier  person  trying  In 
hi  i  p  him  (isefu/.’y  employed. 

•  Conclusion:  This  case  study  confirms  that 
overhead  services  for  1)01) -related  manufac¬ 
turing  industries  are  a  major  cost  factor.  (The 
same  conclusion  was  derived  from  the  com¬ 
parative  statistics  lor  “administrative,  clerical, 
and  sales” labor.  See  IMPORTANT  CHARAC¬ 
TERISTICS  OF  DOD  PROCUREMENT  above.) 
It  is  again  concluded  that  computer  based 
management  and  engineering  aids  to  increase 
t hi*  productivity  and  efficiency  of  indirect  la¬ 
bor  are  of  great  poten  ial  importance. 

An  analysis  was  it,  ale  of  the  existing  pro¬ 
duction  control  system  at  Western  dear,  a 
package  called  SCOPE  (Scheduling  hv  Com 
puter  and  Overall  Production  Evaluation).  It 
was  developed  by  the  corporate  computer 
center  for  use  by  Production  Control. 

SCOPE,  like  many  other  production  control 
systems  observed,  is  a  hatch  system  useful 
only  for  rough  job  scheduling  and  monitoring. 
The  ma|or  input  is  a  Manuluolnnng  Order 
and  its  scheduled  (omplelion  dale,  ho  h  pie 
pared  manually  bv  I’roihe  lion  Control.  Its 
major  outputs  are:  1)  shop  dispatch  cards,  one 
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for  each  operation  scheduled;  and  2)  semi- 
weekly  reports  for  Production  Control,  Ac¬ 
counting,  the  Manufacturing  Manager,  and 
several  managers  reporting  to  him. 

Reporting  of  work  accomplished  is  manual. 
Conflicts  for  resources  and  other  problems 
which  produce  deviations  from  scheduled 
completion  dates  must  be  resolved  manually. 
No  useful  exception  reports  are  available. 

Analysis  of  the  use  of  the  SCOPE  system 
produced  the  following  observations: 

1)  The  Manufacturing  Manager  is  charged 
$15,000  per  month  for  the  service;  for  that  he 
receives  a  set  of  "tab  runs”  twice  a  week,  The 
information  is  too  voluminous  to  be  used  ef¬ 
fectively. 

2)  The  Manufacturing  Manager  has  come  to 
believe  that  it  is  difficult  to  make  small 
changes  to  the  existing  system  to  improve  its 
accuracy  or  functional  capability. 

3)  The  Manufacturing  Department  is  re¬ 
quired  by  corporate  policy  to  purchase  all 
programming  and  processing  services  from 
the  Computer  Center,  and  is  not  permitted  to 
seek  alternatives  outside  the  company. 

4)  The  job  shop  environment  is  extremely 
dynamic;  priorities  change  on  a  daily  -- 
sometimes  hourly  --  basis.  Management  deci¬ 
sions  are  continually  required,  often  bared  on 
data  which  is  not  available  in  any  formal 
s\  stem. 

5)  Control  of  resources  on  an  hourly  basis  is 
currently  performed  manually.  Each  morning 
the  Manufacturing  Manager  prepares  a  new 
list  of  critic;  !  jobs  and  questions.  Prom  7:00 
a.m.  to  tt:3<)  a.m.  he  meets  with  key  members 
of  his  stall  to  request  the  umimfe  current 
status  of  the  jobs:  what  has  been  completed. 


what  is  in  process,  what  problems  prevent  the 
schedules  from  being  met,  and  where  every 
critical  part  is  located.  His  subordinates  are 
instructed  to  gather  information  by  person¬ 
ally  touring  the  shops,  not  just  relying  on  the 
computer  listings.  As  the  reports  are  pre¬ 
sented  to  him,  the  manager  manually  deter¬ 
mines  job  priorities  and  gives  orders  for  the 
rescheduling  of  personnel  and  equipment  to 
overcome  the  critical  problems.  The  manager 
spends  the  rest  of  each  day  following  the 
progress  of  these  items,  trying  to  anticipate 
what  future  bottlenecks  he  created  with  that 
day's  decisions,  and  preparing  instructions  for 
the  night  shifts  to  correct  do\  iations  from  his 
morning  plams  that  occurred  during  the  day 
due  to  unpredictable  variahles. 

•  Conclusion:  There  is  a  requirement  for  real 
time  industrial  information  and  control  sys¬ 
tems  which: 

1)  are  timely,  accurate,  and  reliable: 

2)  are  flexible  and  modifiable; 

3)  interface  directly  to  managers  having  the 

responsibility  for  control;  and 

4)  aid  managers  in  predicting  the  conse¬ 
quences  of  actions  and  decisions. 

To  meet  these  requirements,  a  level  of  sophis¬ 
tication  is  required  in  real  time,  interactive 
software  systems  which  is  noi  currently 
available  in  .in  industrial  environment. 

\/  ('.  Fabrication  Department.  Dan  gins 
tirerajt  (  ani[>an\ 

The  analysis  ol  the  Numerical  Control  (NV 
C)  Fabrication  Department  at  Douglas  Air¬ 
craft  Company  concentrated  on  the  manage¬ 
ment  control  center  currently  in  use  there  to 
control  the  many  complex  jobs  and  resources 
in  that  job  shop  environment. 
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Figure;  ti.f>  shows  sunn;  of  the  wall  displays 
in  the  management  con  ml  center.  This  system 
effectively  portrays  a  massive  amount  of  in¬ 
formation  in  summary  form.  Because  the 
number  of  relationships  between  the  data  are 
effectively  infinite,  little  attempt  at  dynamic 
preplanning  can  occur.  As  a  result,  crises  oc¬ 
cur  regularly.  The  ixicurrence  of  crises  neces¬ 
sitates  a  daily  meeting  of  the  manager  with 
shop  personnel  during  which  additional  in 
formation  is  interchanged  and  solution  strate¬ 
gies  are  developed 

The  manual  data  i  enter  has  made  it  more 
efficient  for  the  manager  to  make  and  imple¬ 
ment  some  decisions,  hut  it  supports  onlv  a 
part  of  his  responsibilities,  lie  still  spends  the 
first  two  horns  every  day  meeting  with,  his 
staff  and  reviewing  the  status  ol  critical  jobs 
from  a  checklist.  The  rest  ol  the  day  he  and 
his  stall  physically  track  down  the  location 
and  condition  ol  parts  and  supplies,  give  or¬ 
ders  to  nine  them,  and  instruct  i  perators  to 
change  the  priority  of  their  eitorls. 

Analysis  ol  this  lacility  .'.as  supported  the 
conclusions  reached  in  the  slmK  ol  produi 
lion  at  Western  dear  (Corpora  I  ion  real  tune 
software  systems  currently  available  as  man 
agemenl  aids  lor  job  shop  eiw  iionments  are 
too  costly,  tin  nd1e\ible.  and  do  not  suppoil 
the  important  management  Imulion  ol  pn 
dieting  consequences  ol  incremental  <  li.mges 
to  existing  schedules.  An  enliedy  new  level  ol 
sollware  sophistication,  at  a  reasonable  cost,  is 
required  Increased  product i\ it \  is  possible 
through  nun  li  more  ellu  lent  utilization  ol 
resources,  it  truly  ellective  job  shop  prodoi 
lion  control  systems  aie  developed.  Initial 
studies  show  ihe  inhumation  ri.v  irnnmenl  in 
inh  simp  1 1 1< : 1 1 ' 1 1 . h . 1 1 1 1  ill1.1  jiiocess  <  introl  is 


sufficiently  finite  to  permit  development  ol 
the  needed  systems  using  the  latest  state  of 
the  art  software  techniques. 

RECO  M ME M)EI)  DEI  FlAtVMEM 
PROGRAM 

These  analyses  have  documented  the 
unique  aspects  ol  manufacturing  for  1J()1) 
procurement,  the  important  leverage  that 
1)01)  has  in  introducing  new  manufacturing 
technologies,  and  the  real  needs  of  mamifac 
hirers  for  new  technologies  shown  by  discus¬ 
sions  with  line  management  personnel  and  by 
analyses  of  their  operations. 

Based  on  these  studies,  i!  was  concluded 
that  an  K&l)  program  in  computer-based 
ir.amilactnriiig  systems  can  have  an  impor¬ 
tant  impact  on  manufacturing  productivity. 
This  K<Sd)  program  should  be  focused  m  two 
areas: 

1)  development  of  a  flexible  m.imifac'iiring 
process  control  system,  and  its  test  and 
evaluation  by  in  plant  use: 

2)  continued  lesearch  in  the  programmable 
manipulation  of  objects,  with  experiments 
designed  to  hi  tlei  understand  ihe  trade  oil’s 
involved  in  assembly,  material  ti.mslei 
machine  loading,  and  other  tasks  involving 
mechanical  dexterity . 

Knob  recommend  it  ion  is  discussed  briefly  he 
low. 

I'lrxihlr.  Maun gc  Ih  ivuli  il 

Mann  fat  turina  /Voce* .«  < antral  M  s/eui 

Process  control  normally  rclers  to  tin-  con 
I  ml  ol  conlmiiou'i  pi  messes,  such  as  oil  or 
sice!  pmd:i<  lion.  Pint  css  control  svsleuis  must 
be  highly  o  b.dile.  real  lime  systems  <<>pjhi< 
ot  peihummg  iniilml  I  unctions,  as  wli  as 
momtormg.  i  )m  pc m. i r;  in  omniendatinn  is 
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that  a  system  with  these  same  attributes  is 
vitally  needed  to  assist  in  the  control  of  the 
batch  production  of  discrete  manufactured 
products.  The  difference  in  the  case  of  discrete 
manufacture  (and  the  primary  reason  effec¬ 
tive  control  systems  do  not  currently  exist  in 
that  environment)  is  that  the  complexity  and 
dynamic  nature  of  hatch  production  require 
continuous,  high-level  decision-making  by  a 
human  manager.  What  he  needs  to  control  his 
resources  effectively  is  a  computer-based  con  - 
trol  system  with  sufficient  flexibility  and  an 
interface  designed  explicitly  for  his  use;  this 
system  must  also  interface  directly  with  his 
resources  in  that  dynamic  environment. 

The  important  functional  requirements  of  a 
Manufacturing  Process  Control  (MPC)  system 
are  to: 

1)  give  the  manager  accurate  answers  to 
common  questions,  such  as  the  status  of  an 
order,  the  location  of  a  part,  etc.: 

2)  provide  him  or  others  exception  reports 
when  specified  limit  conditions  have  Ixien 
reached,  and  enforce  a  user  response: 

2)  provide  status  displays  for  critical  opera¬ 
tions.  and  enforce  user  response  to  certain 
conditions: 

4)  enable  the  manager  to  communicate  with 
and  control  certain  personnel,  as  well  as 
leave  a  recorded  audit  trail: 

a)  allow  the  manager  to  control  the  alloca¬ 
tion  of  key  items  of  equipment  directly 
with  the  computer: 


6)  allow  him  to  explore  the  consequences  of 
potential  decisions; 

7)  he  flexible,  so  that  the  manager  himself 
can  make  small  changes  in  its  functons  as 
his  needs  change  without  system  redevel¬ 
opment: 

8)  he  usable  directly  by  the  manager,  with 
an  interface  he  finds  natural  to  his  task. 

Where  possible,  the  system  should  be  capa¬ 
ble  of  making  sulxr-linuto  decisions  according 
to  acceptable  rules  consequent  to  one  of  the 
manager's  decisions.  When  adequate  algo¬ 
rithms  or  heuristics  exist  for  the  system  to 
make  decisions  independent  of  human  inter¬ 
vention.  the  manager  may  decide  that  they 
should  he  incorporated  into  tue  system.  This 
should  require  that  other  functions  of  the 
system  lx*  impacted  minimally. 

For  the  manager  to  maintain  control  of  the 
plant,  the  system  must  automatically  monitor 
the  status  of  selected  operations  in  the  plant 
and  report  exceptions  so  that  immediate  ac¬ 
tion  may  he  taken  if  necessary.  Furthermore, 
for  control  to  he  maintained,  the  system 
should  noti'y  subordinates  of  actions  to  he 
taken  at  appropriate  times  and  log  the  re¬ 
sponses  of  the  subordinates. 

In  order  for  the  MPC  system  to  have  maxi¬ 
mum  transferability  to  a  variety  of  industrial 
management  environments,  and  to  have  suf¬ 
ficient  reliability  to  be  trusted  by  a  manager 
as  iht:  process  control  system,  it  must  adhere 
to  the  highest  industrial  software  engineering 
standards: 

•  modular  (independence  el  function,  small 
blocks  of  code) 
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•  program  and  data  independence 

•  use  standard  languages 

•  independence  from  operation  systems 

•  minimal  use  of  machine-dependent  code 

•  transaction  -based 

•  interface  to  batch  processing 

•  interface  to  other  systems 

•  checkpoint/restart 

•  fail  -soft 

•  self-monitoring 

•  comple  tely  documented 

•  thoroughly  tested  by  people  independent 

of  the  development  group. 

A  Manufacturing  Process  Control  system  is 
proposed  which  is  highly  reliable  and  yet 
which  incorporates  flexibility  and  an  inter¬ 
face  tailored  explicitly  for  use  by  a  produc¬ 
tion  manager.  The  key  to  such  a  system  is  the 
system  architecture  in  Figure  (i.6. 

System  A  is  stand-alone  and  performs  real 
time  data  acquisiton,  monitoring,  and  resource 
control  functions.  It  must  he  highly  reliable, 
fail -soft,  and  have  the  other  attributes  of  a 
process  control  system.  It  has  significant  data 
acquisition,  medium -speed  storage,  and  user 
output  capabilities,  hut  a  limited  inquiry  and 
command  interpretation  capability  --  most 
probably  with  a  highly  stylized  syntax.  Sys 
tern  A  is  capable  of  requesting  assistance  and 
receiving  commands  from  System  B.  System  B 
is  potentially  shared  and  potentially  remote. 
It  most  probably  relies  on  an  internal  concep¬ 
tual  mode!  of  the  environment  to  perform  a 
degree  of  specialized  language  interpretation 
and  modeling. 


i 


Senion  end 
terminal  interface* 


Figure  6. 6  Proposed  manufacturing 
process  control  system  architecture . 

When  System  A  receives  a  query  or  com¬ 
mand  it  cannot  interpret,  that  input  is  passed 
on  to  System  B;  B  is  capable  of  requesting 
relevant  data  from  A  (possibly  using  the  same 
limited  query  format  as  the  terminal  interface 
to  A).  The  resources  available  in  B  are  used  on 
a  demand  basis.  B’s  capabilities  can  be  ex¬ 
panded  as  technology  or  demand  permits, 
without  compromising  the  integrity  of  System 
A.  System  B  should  utilize  existing  system 
components  to  the  extent  possible. 

This  framework  permits  the  gradual  mtroduc- 
tiaa  of  user -oriented,  flexible,  interactive  software 
into  (be  manufacturing  environment  having  Ilia 
greatest  potential  payoff:  a  complex,  hatch -pro 
dilution  manufacturing  operation 


85 


PROGRAMMED  AUTOMATION 


Research  in  Manipulation  and  Assembly 

The  second  major  recommendation  is  that 
ARPA  continue  a  research  program  in  com¬ 
puter  control  of  machines  applied  to  practical 
assembly  and  manipulative  tasks  in  a  factory 
environment.  ARPA  should  be  especially  re¬ 
ceptive  to  proposals  for  research  on  assembly 
tasks  related  to  electronic-based  units  such  as 
avionic  equipment,  small  radar  and  commu¬ 
nications  units,  and  missile  guidance  units. 
Many  reasons  for  this  emphasis  have  emerged 
from  this  study: 

1)  Assembly  workers  constitute  42  percent 
of  all  employees  in  communications  and 
electronic,  equipment  industries. 

2)  llOD's  demand  for  electronics  appears  to 
be  constant  volume  rather  than  constant 
function;  therefore  significant  assembly 
tasks  will  remain  in  spite  of  the  continuing 
revolution  in  electronics  technology. 

3)  The  consistently  small  size  and  weight  of 
electronic  components  simplify  the  me¬ 
chanical  requirements  in  constructing  a 
prototype  assembly  machine,  and  the  re¬ 
sulting  muchinefs)  could  be  broadly  appli¬ 
cable  to  many  different  electronic -based 
products. 

4)  A  prime  requirement  in  electronic  fabri¬ 
cation  is  the  integration  of  testing  proce¬ 
dures:  greater  mechanization  oi  the  fabrica¬ 
tion  tasks  would  permit  more  timely.  Ihor 
ough.  computer -controlled  testing  to  be  in 
trod uced  into  the  fabrication  process. 

A  flexible,  programmable  electronic,  unit 
assembly  machine  would  be  especially  useful 
in  'hi  construction  of  prototypes.'  there  is 
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often  a  requirement  for  10.  or  50,  or  100  iden¬ 
tical  units  for  testing  {e.g„  destructively,  in  a 
missile  or  smarl  bomb).  It  is  currently  very 
difficult  to  assure  that  such  prototype  units 
are.  in  fact,  fabricated  identically  by  hand.  A 
preliminary  examination  of  electronic  equip¬ 
ment  assembly  operations  indicates  that  this 
is  also  an  area  in  which  considerable  com¬ 
puter-based  machine  flexibility  is  required. 
The  nature  of  the  physical  processes  involved 
leads  to  such  conditions  as  accidental  drops  of 
solder  causing  unexpected  circuit  errors,  and 
jiggling  heuristics  needed  for  proper  plug  and 
board  insertions.  (There  is  also  an  important 
need  to  explore  redesign  possibilities  for 
plugs,  sixikets.  and  components  to  make  them 
more  amenable  to  manipulation  by  machine.) 
Much  of  the  research  on  manipulation  and 
machine  dexterity  performed  in  the  area  of 
electronic  unit  fabrication  will  be  relevant  to 
the  more  difficult  and  more  varied  task  of 
mechanical  assembly  of  discrete  objects. 

We  strongly  recommend  that  any  K&l) 
program  in  automation  of  assembly  tasks  be 
based  on  the  validation  procedures  which  we 
have  used  in  the  present  study: 

1)  perform  case  analyses  of  electronics  fab¬ 
rication  operations  currently  being  jiei 
formed,  and  obtain  estimates,  from  manu¬ 
facturing  representatives  with  line  respon 
sibility.  ot  the  expected  changes  in  labrica 
lion  technology  to  be  utilized  h\  their  lacil 
ity  (luring  the  next  decade: 

2)  form  an  Advisory  Council  of  line  iminii 
facturing  ru|iresentalives  to  validate  tin* 
conclusions  o!  that  study  and  the  lime 
tional  specilications  derived  from  it  fur  i 
prototype  machine: 
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3)  perform  an  R&D  program  in  cooperation 
with  representatives  of  relevant  industry 
groups  to  develop  prototype  systems: 

4)  arrange  for  on-site  test  and  evaluation  of 
prototype  systems  in  actual  production  en¬ 
vironments. 

FUTURE  RESEARCH  AM) 
DEVELOPMENT 

In  the  next  year  a  development  program  at 
1S1  has  been  proposed  for  a  flexible  manage¬ 
ment  system  for  the  control  of  production.  It 
is  intended  that  this  system  be  broadly  appli¬ 
cable  to  the  control  function  in  diverse  batch 
production  manufacturing  environments,  thus 
achieving  the  maximum  possible  effect  on  the 
productivity  of  major  1)01)  suppliers.  It  is 
planned  to  draw  upon  the  resources  of  the 
software  system  research  being  performed 
withir,  the  AKPA  community  of  contractors, 
and  to  enter  into  explicit  relationships  with 
industries  which  will  allow  the  transfer  of 
the  resulting  technology  for  test  and  evalua¬ 
tion.  It  is  expected  that  a  System  A  will  be 
operational  in  one  or  more  factory  environ¬ 
ments  within  eighteen  months:  this  initial 
“window”  into  the  information  and  control 
flow  in  the  factory  will  then  allow  the  intro¬ 
duction.  test,  and  evaluation  of  various  Sys¬ 
tem  B  advanced  capabilities. 
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IXTRODl'CTIOS 

The  1S1  time  sharing  facility  is  operated  as 
a  research  and  service  center  in  support  of  a 
broad  set  if  ARPA  projects,  it  currently  serv¬ 
ices  400  users.  of  whom  access  the  facili 
ties  via  the  ARPANET  from  locations  ex¬ 
tending  from  the  East  Coast  to  Hawaii.  AH 
facilities  of  the  opera'ing  system  are  available 
to  all  users,  independent  of  whether  they  are 
locally  or  remotely  connected  through  the 
ARPANET. 

The  system  consists  of  a  PDP-10  CPU.  Holt 
Reranek  and  Newman  (BBN)  paging  box. 
large  capacity  memory,  high-performance 
paging  drum,  on-line  f>!e  storage,  and  associ¬ 
ated  peripherals  (see  Figure  7.1).  I’he  TENEX 
operating  system,  in  conjunction  with  the 
large  core  and  drum  memory,  provides  con¬ 
siderable  computing  capacity  and  is  capable 
of  supporting  a  wide  variety  of  simultaneous 
users. 

In  increase  system  availability,  additions 
have  been  made  in  the  hardware  and  soft¬ 
ware  facilities  and  in  support  personnel.  As  a 
result,  system  usage,  both  by  IS1  and  nun- 
Institute  users,  has  expanded  greatly  during 


1‘iojert  Leader: 
Rewurth  St<tfj: 

Reseanl  Support  Staff: 

Student  I  ides: 


John  T.  MH  >  in 

Thomas  I..  Itovnlon 
Siuar!  <!.  Frigin 
Itol-crl  II.  I'arkrr 
l.en. v  Itirliankin 

Ju«K  (iiislaFon 
Mar\  J.  Jaskula 
Jrrr\  l*i,  >«•* 

IkiMiionil  I..  Hale* 
Dannv  I..  <  harlr-worlli 
Ituiulil  I.,  Currier 
Jimmy  T.  koila 
\  irgiitiu  I1..  Sato 


the  eight  months  the  facility  has  been  in 
operation. 

I  itl vo  Display  System 

A  Video  Display  System  is  being  developed 
to  provide  an  inexpensive  quality  terminal  for 
computer  users  (i.e.,  programmers,  managers, 
secretaries)  requiring  significantly  more  capa¬ 
bilities  than  currently  available  with  low  cost 
terminals,  These  capabilities  include:  a  full 
page  of  text  (4,000  characters),  graphics.  256 
words  of  writable  font,  and  a  standard  com¬ 
munications  interlace  to  facilitate  computer 
connection.  A  modular  design  (part  of  the 
stated  requirements)  will  allow  components 
to  be  used  in  a  clustered  environment  as  well 
as  in  a  remote  stand-alone  unit,  with  mini¬ 
mum  cost  differential.  A  M.equest  for  Proposal 
has  been  distributed  to  twelve  vendors  with 
responses  of  interest  expected  from  at  least 
four  vendors  by  |nne  2‘J.  197,'  1. 

FACILITY  ESTABUSIIMEX T 

l  ire  system  was  moved  from  another  loca 
lion  in  the  beginning  of  October  1972.  Several 
months  prior  to  the  move,  considerable  effort 
was  spent  preparing  the  Institute  site  for  the 
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Figure  7.1  TENEX  facility. 


arrival  of  the  computing  equipment.  I’repara 
lions  included  machine  room  layout,  speed)  - 
cation  of  all  environmental  and  electrical  re¬ 
quirements.  overseeing  of  the  installation  of 
t hi;  specified  support  equipment,  and  the 
physical  movement  ol  the  computing  equip¬ 
ment,  The  site,  including  the  computing  sys 
tern,  became  operational  m  early  October. 


GENERAL  SYSTEM  UPGRADES G 

Since  moving  to  these  facilities,  considera¬ 
ble  emphasis  has  hcen  placed  on  increasing 
t he?  availability  of  the  system  for  both  local 
and  ARPANET  users.  To  accomplish  this 
task,  additions  have  been  made  in  hardware 
and  software,  and  in  support  personnel. 

II  n  nhcare 

The  hardware  acquired  since  the  move  to 
ISI  includes  additional  terminal  access  ports 
for  local  users,  magnetic  la|>e  units  for  file 
har.Kup  and  recovery,  and  an  additional  disk 
drive  to  expand  ' ha  system's  on-line  storage 
capability. 

Software 

A  joint  effort  was  undertaken  bv  LSI  and 
the  Network  Information  (’enter  (NIC)  at  the 
Stanford  Research  Institute  to  modify  the  \l(i 
archival  facility  for  use  on  the  TENEX  here. 
I'hi!  facility  was  implemented  so  as  to  allow 
the  system  operator  to  selectively  archive,  to 
magnetic  tape,  user  files  which  have  remained 
dormant  within  the  system.  A  linkage  was 
created  within  the  file  system  so  that  the  user 
can  subsequently  interrogate  the  archive  and 
notify  the  operator  of  his  desire  to  have  the 
file  retrieved.  The  current  implementation  is 
viewed  as  preliminary  and  incomplete.  Addi 
tional  capabilities  and  extensions  are  planned 
and  under  development.  However,  it  is  appar 
(>nt  that  even  the  preliminary  implementation 
is  usable  and  does  prov  ide  the  needed  exten¬ 
sion  to  magnetic  tape  storage. 

Another  system  software  development  el 
fort  concerned  hardware  diagnostics  Digital 
Equipment  Corporation  (DEC)  peripheral  di 
agnostics  have  been  muddied  to  run  under  the 
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operating  system  as  privileged  jobs,  thereby 
reducing  the  amount  of  stand-alone  time  re¬ 
quired  to  perform  preventive  and  corrective 
maintenance.  Other  diagnostics  have  been 
modified  or  developed  to  aid  in  the  identifi¬ 
cation  and  isolation  of  problems  resulting 
from  the  interaction  of  DEC  and  IS1  -built 
equipment. 

Support  Personnel 

The  Institute  has  hired  and  trained  student 
operators  to  provide  twenty -four  hour  ma¬ 
chine  coverage.  The  primary  responsibility  of 
the  operator  is  to  assist  the  system  staff  in 
maintaining  the  operating  system  and  in  the 
continuous  functioning  of  the  overall  system. 
The  or. -duty  operator  is  principally  engaged 
in  runn  ng  system  maintenance  programs  and 
monitoring  machine  room  equipment.  The 
latter  function  includes  detecting  failures  on 
the  computer  or  computer  support  equipment, 
taking  corrective  action,  and  notifying  appro¬ 
priate  system  personnel  in  the  event  of  a 
nonrecoverable  failure. 

A  full-time  system  programmer  has  also 
been  hired,  bringing  the  system  programming 
staff  up  to  one  and  one-half  full-time  person¬ 
nel. 

LOCAL  PROJECT  SUPPORT 

The  TENEX  facility  has  been  uti’ized  ex¬ 
tensively  in  support  of  local  projects.  The  staff 
makes  use  of  all  of  the  available  standard 
subsystems  (e.g.,  editors,  compilers,  assemblers, 
and  utilities).  Additionally,  staff  members 
have  written  subsystems  and  utilities  in  sup 
port  of  their  projects  (e.g..  a  mailing-label 
program,  photo  typesetting  support  programs, 
TENEX  accounting  package  extensions,  and  a 
special  hard  copy  terminal  controller).  The 
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facility  has  supported  less  frequently  used 
subsystems  at  the  special  request  of  users. 

XGP. 

The  installation  of  a  Xerox  Graphics 
Printer  (XGP)  is  planned  to  provide  for  the 
formal  printing  and  graphics  requirements  of 
the  Institute.  The  XGP  is  essentially  a  video 
to  Xerox  hard  copy  device.  The  printer  has 
been  installed  in  several  other  locales,  along 
with  associated  processors  for  converting 
coded  information  to  video  or  raster  data  for 
the  XGP.  It  is  planned  to  increase  the  vertical 
and  horizontal  resolution  oyer  that  currently 
in  use  at  other  sites  in  order  to  producs  the 
high  quality  output  desired.  Since  the  inclu¬ 
sion  of  graphics  will  require  more  processing 
power  than  the  PDP-11  support  processors 
used  at  other  sites,  the  XGP  will  eventually 
be  driven  with  the  speech  processor  described 
in  the  Network -Supporting  Research  section 
of  this  report.  It  is  intended  also  that  the  XGP 
will  be  a  natural  part  of  the  remote  confer¬ 
encing  mechanism  under  development  by  the 
Network  group. 

Also,  modifications  to  the  operating  system 
and/or  special  programs  have  been  written  in 
direct  support  of  Institute  projects. 

W/./’-WW  Proeessor. 

Monitor  modifications  to  support  the  initial 
installation  and  check-out  of  the  MLP-900 
have  been  developed  and  verified.  These  mod¬ 
ifications  allow  basic  processor  to  processor 
communication  through  both  the  I/O  buss 
and  memory.  This  is  step  one  of  the  multistep 
plan  for  fully  integrating  the  MLP  into  the 
TENEX  operating  system.  (See  the  Program 
ming  Research  Instrument  project  report.) 
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\  el  work  Measurements. 

The  system  has  been  utilized  to  obtain 
measurements  of  interest  to  the  Network  pro¬ 
jects.  (See  the  Network -Supporting  Research 
project  report.) 

ARPANET  USAGE  AND 
SUPPORT 

System  usage  by  ARPANET  users  has  in¬ 
creased  significantly  since  the  machine  has 
been  at  IS1.  Prior  to  moving  to  ISI,  Network 
users  numbered  approximately  30.  Since  the 
move,  the  number  has  increased  steadily.  In 
January,  50  Network  users  utilized  30  directo¬ 
ries;  by  March,  350  Network  users  utilized  230 
directories.  Beginning  with  May,  approxi¬ 
mately  400  users  "  ere  using  300  directories. 

All  Network  users  are  assumed  to  be  expe¬ 
rienced  with  the  use  of  TENEX  and  the  AR¬ 
PANET.  Institute  operators  and  staff  members 
have  engaged  in  actively  assisting  Network 
users  and  will  continue  to  do  so.  Of  necessity, 
this  assistance  frequently  must  be  confined  to 
providing  information  on  the  location  of  doc¬ 
umentation,  or  the  names  of  other  non -Insti¬ 
tute  individuals  to  contact  when  the  question 
concerns  non -institute  software. 

VIDEO  DISPLAY  SYSTEM 

A  special  project  has  begun  to  develop  a 
Video  Display  System  to  replace  the  one  for¬ 
merly  available  with  the  TENEX  time  shar¬ 
ing  system.  This  project  will  result  in  the 
procurement  of  a  high  quality  terminal  sys¬ 
tem  for  members  of  the  Institute. 

The  terminals  will  he  part  of  the  user's 
office  environment  and  will  be  used  as  any 
other  tool  (e.g.,  a  telephone)  by  the  staff  in  the 
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performance  of  their  duties.  Most  of  the  of¬ 
fices  are  in  close  proximity  to  a  communica¬ 
tions  processor  (which  is  interfaced  to  the 
ARPANET)  in  a  clustered  environment;  how¬ 
ever.  a  remote  capability  will  be  available. 

The  basic  terminal  consists  of  a  high  qual- 
i*y  TV  monitor,  and  a  keyboard  with  required 
control  logic.  The  terminal  will  be  predomi¬ 
nantly  used  for  text  (alphanumeric)  commu¬ 
nication  with  TENEX;  however,  a  quality 
graphics  capability  is  also  required.  The  prob¬ 
lem  dictating  the  display  system  architecture 
is  how  to  provide  high  quality  graphics  to  a 
limited  number  of  users  without  prohibitively 
taxing,  in  dollars  or  capabilities,  the  text -only 
users.  The  graphics  requirement  has  two  as¬ 
pects:  a  limited  and  unlimited  number  of  vec¬ 
tors.  If  economically  feasible,  all  display  ter¬ 
minals  will  be  provided  with  a  limited 
graphic:,  capability.  The  graphics  requirement 
assumes  compatibility  with  a  variety  of  input 
devices  (e.g.,  light  pen,  tablet,  mouse,  etc.) 
which  can  be  added  to  the  terminal  as  re¬ 
quired. 

Display  System. 

The  display  system  consists  of  digital  gen¬ 
erators  (scan  converter,  character  and  vector 
generators)  for  a  high  resolution  raster  scan 
display.  The  raster  scan  is  required  to  insure  a 
flicker-free  display  without  concern  for  the 
display  content.  The  resolution  of  the  system 
displays  a  full  page  of  text  (typed,  single 
space,  approximately  4,000  characters).  The 
high  resolution  of  the  display  is  also  needed 
for  (he  quality  of  vectors  desired.  The  stipula¬ 
tion  of  an  all  digital  system  is  consistent  with 
a  requirement  for  maintainability  and  reli¬ 
ability.  It  is  aiso  assumed  that  a  quantized 


video  display  produces  better  images,  simpli¬ 
fies  the  video  distribution  system  and  the  TV 
moniiur,  takes  advantage  of  cm  Lent  digital 
technology,  makes  more  feasible  an  all  solid- 
state  approach,  simplifies  the  registration 
problems  with  input  devices,  and  is  more 
compatible  with  a  desired  modular  building 
block  approach. 

Minimal  Centralization. 

An  additional  display  system  design  goal  is 
production  of  a  terminal  that  minimizes  the 
required  centralized  equipment  so  terminal 
remoteness  can  better  be  achieved.  The  mini- 
malized  centralization  reduces  the  per  unit 
cost  differential  of  single  and  multiple  termi- 
nrl  clusters.  For  the  most  part,  the  required 
terminal  configuration  will  be  in  close  prox¬ 
imity  to  the  interfacing  communications 
processor.  Economic  considerations  may  dic¬ 
tate  packaging  some  of  the  components  in  a 
central  unit  or  multiplexing  some  of  the  logic. 
This  economic  advantage  should  not  compro¬ 
mise  the  display  terminal  architecture  in  such 
a  way  that  the  stand-alone  unit  cannot  be 
assembled  from  the  same  set  of  building 
blocks.  The  control  commands,  and  character 
and  vector  order  codes  are  identical  for  the 
local  and  remote  terminals. 

Iluihlinfc  Block*. 

The  clustered  video  terminal  system  is  per¬ 
ceived  as  a  collection  of  building  blocks,  all 
available  on  demand  and  shared  by  the  users 
via  automatic  control.  These  blocks  consist  of 
20  character  and  20  vector  generators,  refresh 
memories,  and  interface  controls  (see  Figure 
7.2).  The  TV  monitor  has  a  raster  format  of 
1,280  points  per  line  and  864  visible  lines.  The 
monitor  operates  with  either  black  or  white 
video,  with  the  predominant  use  to  be  black 
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Figure  7.2  A  clustered,  video 
display  system. 
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on  white.  The  generators  art  interfaced  to  the 
computer  system  vv'ith  up  to  a  19.2  kilobits/ 
second  teletype -like  (El A  RS-232C)  channel. 
These  ports  will  be  provided  by  a  communi¬ 
cations  processor  interfaced  to  the  ARPA 
Network.  The  generators  are  dynamically  tied 
to  the  terminal  through  a  video  switch  and  a 
video  distribution  system  as  required  by  the 
user.  The  raster  refresh  memory  is  also  an  on 
demand  resource  and  is  only  required  for  the 
full  graphics  user. 

Survivability. 

The  display  system  resulting  from  this  pro¬ 
curement  will  be  a  high  quality  state  of  the 
art  instrument  for  the  computer's  user  envi¬ 
ronment.  In  selecting  a  vendor  to  produce  the 
display  system,  consideration  will  lie  given 
not  only  to  his  ability  to  produce  this  proto¬ 
type  system,  but  also  to  insure  product  sur¬ 
vivability  should  the  displays  be  in  demand 
by  others. 

Expandable  System 

The  performance  of  the  terminals  can  be 
expanded  in  a  variety  of  ways,  depending  on 
economic  considerations.  There  are,  however, 
additional  highly  desirable  attributes  for  the 
Institute's  applications  which  will  be  consid¬ 
ered  during  terminal  system  development. 
These  are: 

•  an  open-ended  system  to  allow  for  addi¬ 
tional  terminals  or  generators,  without 
making  existing  hardware  obsolete: 

•  a  two -page  display  of  approximately 
H.000  characters  on  a  single  screen: 

•  variable  character  spacing  up  to  a  maxi¬ 
mum  of  100  characters  per  line: 

•  expansion  of  character  capacity  up  to 
twice  the  present  size: 


•  line  width  control,  rather  than  gray  level 
or  color,  for  video  modifiers. 

The  responses  to  the  Request  for  Proposal 
will  be  reviewed  during  the  month  of  July 
1973.  It  is  anticipated  that  a  contract  will  be 
awarded  during  August  1973  with  a  one-year 
completion  date.  Partial  deliveries  of  termi¬ 
nals  are  expected  throughout  the  >ear  to  re¬ 
place  the  Institute’s  currrently -leased 
terminals. 
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June 

Hurry  Reims,  Gould  Inc.  Gould  printer,  June  29, 
1972. 

July 

Robert  Muzza.  IBM.  Data  communication  study. 
July  21,  1972. 

Rotert  Anderson,  IS1.  Automation,  July  24,  1972. 

Donald  Oestreicher.  ISI.  MLP-900  programming 
languages.  July  27, 1972 

I  u  fin  si 

Martin  Yonke,  1S1.  ML, P-900,  August  7, 1972. 

David  Pa  mas,  Carnegie -Mel  Ion  University.  Re¬ 
sponse  to  errors  in  well -structured  programs, 
August  11, 1972. 

Theodore  Kehl,  Washington  University.  On-line 
computer  systems,  August  21. 1972. 

Gerald  Sussman,  MIT.  Artificial  intelligence,  Au¬ 
gust  22.  1972. 

Karl  Balke,  Burroughs  Cnrp.  Information  systems 
performance  theory,  August  29,  1972. 

September 

Douglas  Hogan,  National  Security  Agency.  MLP- 
9(X)  speech  recognition  and  security,  September 
12, 1972. 

)erry  Elkind,  Xerox  Corp.  Research  programs  at 
Xerox,  September  13, 1972. 

Theodore  Glaser.  Case  Western  Reserve  Univer¬ 
sity.  Vocoders  and  video  bandwidth  reduction 
techniques,  September  15.  1972. 

Robert  Merrell  and  Charles  Seitz,  Burroughs  Corp. 
Video,  September  20, 1972. 

Ralph  London,  1ST  Program  correctness  September 
21.  1972. 

Vint  ('.erf,  Stanford  University,  Network  charac¬ 
teristics.  September  29, 1972, 

Wayne  Wilner.  Burroughs  Corp.  Burroughs  1700 
microprogramming  computer,  Septemher  29, 
1972. 


COLLOQU1A 

May  1972  to  May  1973 


October 

Richard  Bisbey  11,  ISI.  SAAB  FCPU  microprogram¬ 
med  computer,  October  18. 1972. 

Warren  Teitelman,  Xerox  Corp.  BBN-LISP  and 
run-time  enhancements  to  ease  programming, 
October  20. 1972. 

Glen  Culler,  Culler -Harrison  Inc.  SPS-32  signal 
processing  computer,  October  26, 1972. 

Robert  Parker,  1ST  Vocoder  techniques,  October  30, 
1972 

Morember 

Alan  Kay,  Xerox  Corp.  Teaching  programming  to 
children,  November  3,  1972. 

Walter  Martin  and  Martin  Schrage,  Computer  Sig¬ 
nal  Processors,  Inc.  CSP-30  floating  point  proces¬ 
sor,  November  3, 1972. 

Alter!  Zobrist,  USC.  Advice -taking  chess  machine, 
November  6. 1972. 

Donald  Good,  University  of  Texas.  The  NUCLEUS 
verification  system,  November  17, 1972. 

jerry  McClellan,  STANDARD  Computer  Corp.  IC- 
4000,  November  22, 1972. 

December 

William  Pratt,  USC.  Image  processing,  December  1, 
1972. 

James  Mitchell.  Xerox -Palo  Alto  Research  Center. 
Data  extensions,  December  4. 1972. 

Earl  Swartzlander,  USC.  The  inner  product  com¬ 
puter,  Deeemher  19,  1972. 

January  1973 

Don  Blankenship,  University  of  California  at  San 
Diego,  judgements  of  temporal  sequence,  january 
4,  1973. 

judy  Townley,  Harvard  University.  KCL  funda¬ 
mentals,  january  10,  1973. 

Thomas  Cheatham  and  fames  Forgle  Harvard 
University.  Advanced  concepts  in  utilization, 
january  11, 1973. 

jaimie  Carhoiiell,  Bolt  Beranek  and  Newman  Inc. 
Mixed  initiative  manned  machine  systems,  jan¬ 
uary  12  1973. 
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COLLOGUIA 


Rob  Kling,  University  of  Wisconsin.  Fuzzy  set 
theory  with  PLANNER,  January  12, 1973. 

Rob  Kling,  University  of  Wisconsin.  Toward  a 
person -centered  computer  science,  January  12, 
1973. 

Karl  Balke,  ISI.  Performance  theory,  January  15. 
1973. 

Ronald  Reseh,  University  of  Utah.  Computer 
seulpture/architecture  models,  January  25, 1973. 

February 

James  Levin,  University  of  California  at  San  Diego. 
Models  of  human  inference,  February  5,  1973. 

Patrick  Baudelaire.  University  of  Utah.  Color  per¬ 
ception.  Fehruary  6, 1973. 

Eduardo  Fernandez,  University  of  California  at  Los 
Angeles.  Activity  transformations  in  a  graph 
model  of  parallel  computations,  February  7, 
1973. 

Barry  Wessler,  University  of  Utah.  Computer  ani¬ 
mation,  Fehruary  15.  1973. 

Guner  Robinson,  ISI.  Survey  of  speech  processing 
techniques  for  vocoding  purposes,  Fehruary  20, 
1973. 

Guner  Robinson,  ISI.  Details  of  the  linear  predic¬ 
tive  coding  techniques  for  speech  compression, 
Fehruary  28, 1973. 

March 

Louis  Mailloux,  Xerox  Corp.  Presentation  on  the 
Xerox  Graphics  Printer,  March  1, 1973. 

James  Morris,  Jr„  University  of  California  at 
Berkeley.  Protection  in  programming  languages, 
March  7,  1973. 

William  Quirk,  Naval  Air  Development  Center. 
Mid-1960s  Booing  Aircraft  experiment  on  dis¬ 
tributed  project  management -conferencing  and 
its  relation  to  ARPANET  conferencing,  March  7. 
1973. 

William  |oyner.  Harvard  University.  Automatic 
theory  proving  and  the  decision  problem,  March 
H,  1973. 


Anita  Jones,  Carnegie -Mellon  University.  Protec¬ 
tion  in  programming  systems,  March  14, 1973. 

Peter  Pettier,  Di Phase  Corp.  Presentation  on  porta¬ 
ble  terminals,  March  15.  1973. 

Larry  Snyder,  Carnegie -Mel Ion  University.  Analy¬ 
sis  of  programming  language's  using  schemata, 
March  15, 1973. 

Daniel  Swinehart,  Stanford  University.  A  multi  - 
process  approach  to  interactive  programming 
systems,  March  16, 1973. 

Kenneth  Modesitt,  Purdue -Ft.  Wayne.  ELIJAH  - 
an  intelligent  assistant  for  natural  language  pro¬ 
gramming,  March  19, 1973. 

Stephen  Jones,  Southern  Methodist  University. 
Adaptive  filters,  March  20, 1973. 

Stephen  Jones,  Southern  Methodist  University. 
Speech  processing,  March  20, 1973. 

James  Watt,  Burroughs  Corp.  Presentation  on  Self- 
Scan,  March  22, 1973. 

Thomas  Moran,  Carnegie -Mellon  University.  The 
symbolic  nature  of  visual  imagery,  March  30, 
1973. 

April 

Robert  Furey,  Lockheed  Corp.  Presentation  on  SUE 
eompuL  -s  April  11, 1973. 

William  Howden,  University  of  California  at  Ir¬ 
vine.  Naive  problem  solving,  April  18. 1973. 

May 

Alexander  Christakis,  Academy  for  Policy  Analy¬ 
sis.  Socio -planetarium,  May  7, 1973. 

Norton  Greenfeld,  California  Institute  of  Technol¬ 
ogy.  Optimization  in  relational  data  base  sys¬ 
tems.  May  8,  1973. 

Leon  Stuck!,  McDonnell -Douglas  Astronautics  Co. 
Automatic  generation  of  self-metric  software, 
May  9, 1973. 

David  Wile,  Carnegie -Mol Ion  University.  A  gener¬ 
ative,  nestl'd -sequential  basis  for  general -pur¬ 
pose  programming  languages.  May  10.  1973. 

Walter  Ryder,  USC.  The  role  of  formal  decision  - 
making  methods  in  interactive  management 
systems.  May  11,  1973 
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9  PUBLICATIONS 


1  Anderson,  Robert  H„  Programmable  Auto¬ 
mation:  The  Future  of  Computers  in  Manu- 
facturing.  USC/lnformation  Sciences  Insti¬ 
tute,  RR-73-Z  March  1973;  also  appeared  in 
Datamation,  Vol.  18,  No.  12,  December  1972, 
pp.  46  -52. 

2  - ,  and  Nake  M.  Kamrany,  Advanced 

Computer-based  Manufacturing  Systems  for 
Defense  Needs,  USC/lnformation  Sciences 
Institute,  RR-73-10,  (in  progress). 

3  Balzer,  Robert  M„  Automatic  Programming, 
USC/lnformation  Sciences  Institute.  RR-73- 
1,  (draft). 

4  - ,  CASAP:  A  Test  bed  for  Program  Flex¬ 

ibility,  USC/lnformation  Sciences  Institute, 
RR-73-5,  (in  progress). 

5  - .  Another  Look  at  Program  Organiza¬ 

tion,  USC/lnformation  Sciences  Institute, 
RR -73-6,  (in  progress). 

6  - ,  Human  Use  of  World  Knowledge, 

USC/lnformation  Sciences  Institute,  RR-73- 
7,  (in  progress). 

7  - ,  A  Global  View  of  Automatic  Pro¬ 

gramming.  USC/lnformation  Sciences  Insti¬ 
tute,  RR-73-9,  (in  progress). 

8  Ellis,  Thomas  0.,  Louis  Gallenson,  John  F. 
Heafner,  and  John  T.  Melvin,  A  Plan  for 
Consolidation  and  Automation  of  Military 
Telecommunications  on  Oahu,  USC/lnfor¬ 
mation  Sciences  Institute.  RR-73-12,  May 
1973. 


9  Igarashi,  Shigeru,  Ralph  L  London,  and  Da¬ 
vid  C.  Luckham,  ‘'Automatic  Program  Veri¬ 
fication  I:  Logical  Basis  and  Its  Implementa¬ 
tion",  Artificial  Intelligence  Memo  200, 
Stanford  University,  May  1973;  also  USC/ 
Information  Sciences  Institute,  RR-73-11, 
May  1973. 

10  Kamrany,  Nake  M.,  A  Preliminary  Analysis 
of  the  Economic  Impact  of  Programmable 
Automation  Upon  Discrete  Manufacturing 
Products,USC/!nformation  Sciences  Institute, 
RR-73-4, (in  progress). 

11  Oestreicher,  Donald  R.,  A  Microprogram¬ 
ming  Language  for  the  MLP-900,  USC/ln- 
formaMon  Sciences  Institute,  RR-73-8.  June 
1973;  will  also  appear  in  the  Proceedings  of 
the  ACM  Sigplan  Sigmicro  Interface  Mend¬ 
ing,  New  York,  May  30  -  June  1,  1973. 

12  Rosenberg,  Jack,  A  History  of  Numerical 
Control  V. 949  -  1972:  The  Technical  Devel¬ 
opment,  Transfer  to  Industry,  and  Assimila¬ 
tion.  USC/lnformation  Sciences  Institute, 
RR-73-3,  (in  progress). 
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